SE-TEXT-BOOK_Material.doc

GPCET, Department of CSE
TABLE OF CONTENTS
Content Page No
UNIT 1
1.0 SOFTWARE AND SOFTWARE ENGINEERING 1
1.1 THE NATURE OF SOFTWARE 2
1.2 THE UNIQUE NATURE OF WEBAPPS 6
1.3SOFTWARE ENGINEERING 7
1.4 THE SOFTWARE PROCESS 8
1.5 SOFTWARE ENGINEERING PRACTICE 10
1.6 SOFTWARE MYTHS 12
1.7 A GENERIC PROCESS MODEL 14
1.8 PROCESS ASSESSMENT AND IMPROVEMENT 17
1.9 PRESCRIPTIVE PROCESS MODELS 18
1.10 SPECIALIZED PROCESS MODELS 25
1.11 The UNIFIED PROCESS 26
1.12 PERSONAL AND TEAM PROCESS MODELS 27
1.13 PROCESS TECHNOLOGY 29
1.14 PRODUCT AND PROCESS 29
1.15 WHAT IS AGILITY? 31
1.16 AGILITY AND THE COST OF CHANGE 31
1.17 WHAT IS AN AGILE PROCESS 32
1.18 EXTREME PROGRAMMING (XP) 35
1.19 OTHER AGILE PROCESS MODELS 38
UNIT 2
2.0 UNDERSTANDING REQUIREMENTS 44
2.1 REQUIREMENTS ENGINEERING 45
2.2 ESTABLISHING THE GROUNDWORK 46
2.3 ELICITING REQUIREMENTS 47
2.4 DEVELOPING USE CASES 49
2.5 BUILDING THE REQUIREMENTS MODEL 50
2.6 NEGOTIATING REQUIREMENTS 53
2.7 VALIDATING REQUIREMENTS 53
2.8 REQUIREMENTS MODELING (SCENARIOS,
54
INFORMATION AND ANALYSIS CLASSES)
2.9 REQUIREMENTS MODELING (FLOW, BEHAVIOR,
70
PATTERNS AND WEBAPPS)
2.10 PATTERNS FOR REQUIREMENTS MODELING 76
2.11 REQUIREMENTS MODELING FOR WEBAPPS 79

Software Engineering Lecture notes
Content Page No
UNIT 3
3.1 DESIGN WITHIN THE CONTEXT OF SOFTWARE ENGINEERING 85
3.2 THE DESIGN PROCESS 86
3.3 DESIGN CONCEPTS 88
3.4 THE DESIGN MODEL 93
3.5 SOFTWARE ARCHITECTURE 97
3.6 ARCHITECTURAL STYLES 100
3.7 ARCHITECTURAL DESIGN 104
3.8 ASSESSING ALTERNATIVE ARCHITECTURAL DESIGNS 107
3.9 ARCHITECTURAL MAPPING USING DATA FLOW 108
3.10 Component-Level Design 112
3.11 DESIGNING CLASS-BASED COMPONENTS 116
3.12 COMPONENT-LEVEL DESIGN FOR WEBAPPS 123
3.14 COMPONENT-BASED DEVELOPMENT 126
UNIT 4
4.0 USER INTERFACE DESIGN 130
4.1 THE GOLDEN RULES 131
4.2 USER INTERFACE ANALYSIS AND DESIGN 133
4.3 INTERFACE ANALYSIS 135
4.4 INTERFACE DESIGN STEPS 139
4.5 WEBAPP INTERFACE DESIGN 142
4.6 DESIGN EVALUATION 146
4.7 WEBAPP DESIGN 147
4.8 CONTENT DESIGN 151
4.9 ARCHITECTURE DESIGN 152
4.10 NAVIGATION DESIGN 155
4.11 COMPONENT-LEVEL DESIGN 155
4.12 OBJECT-ORIENTED HYPERMEDIA DESIGN METHOD (OOHDM) 156

Content Page No
UNIT 5
5.0 SOFTWARE TESTING 158
5.1 A STRATEGIC APPROACH TO SOFTWARE TESTING 159
5.2 STRATEGIC ISSUES 162
5.3 TEST STRATEGIES FOR CONVENTIONAL SOFTWARE 163
5.4 TEST STRATEGIES FOR OBJECT-ORIENTED SOFTWARE 170
5.5 TEST STRATEGIES FOR WEBAPPS 172
5.7 SYSTEM TESTING 174
5.8 THE ART OF DEBUGGING 175
5.9 TESTING CONVENTIONAL APPLICATIONS 179
5.10 TESTING FOR SPECIALIZED ENVIRONMENTS, ARCHITECTURES,
APPLICATIONS
197
5.11 PATTERNS FOR SOFTWARE TESTING 199
5.12 TESTING OBJECT ORIENTED APPLICATIONS 201
5.13 INTERCLASS TEST-CASE DESIGN 209
SHORT ANSWERS 212
BIT QUESTIONS AND ANSWERS 230
INTERNAL AND EXTERNAL QUESTION PAPERS 234
QUESTION BANK 242
TOPICS TO REMEMBER 245

GPCET, Department of CSE | 1
UNIT – 1
1.0 SOFTWARE AND SOFTWARE ENGINEERING
What is it? Computer software is the product that software professionals build and then
support over the long term. It encompasses programs that execute within a computer of any
size and architecture, content that is presented as the computer programs execute, and
descriptive information in both hard copy and virtual forms that encompass virtually any
electronic media. Software engineering encompasses a process, a collection of methods
(practice) and an array of tools that allow professionals to build high quality computer
software.
Who does it? Software engineers build and support software, and virtually everyone in the
industrialized world uses it either directly or indirectly.
Why is it important? Software is important because it affects nearly every aspect of our
lives and has become pervasive in our commerce, our culture, and our everyday activities
Software engineering is important because it enables us to build complex systems in a timely
manner and with high quality.
What are the steps? You build computer software like you build any successful product,by
applying an agile, adaptable process that leads to a high-quality result that meets the needs
of the people who will use the product. You apply a software engineering approach.
What is the work product? From the point of view of a software engineer, the work product
is the set of programs, content (data), and other work products that are computer software.
But from the user’s viewpoint, the work product is the resultant information that somehow
makes the user’s world better.
Unit I:
Software and Software Engineering: The Nature of Software, The Unique Nature of WebApps,
Software Engineering, The Software Process, Software Engineering Practice, Software Myths
Process Models: A Generic Process Model, Process Assessment and Improvement, Prescriptive
Process Models, Specialized Process Models, The Unified Process, Personal and Team Process
Models, Process Technology, Product and Process.
Agile Development: Agility, Agility and the Cost of Change, Agile Process, Extreme
Programming, Other Agile Process Models

1.1 THE NATURE OF SOFTWARE
Today, software takes on a dual role. It is a product, and at the same time, the vehicle
for delivering a product. As a product, it delivers the computing potential embodied by
computer hardware or more broadly, by a network of computers that are accessible by
local hardware.
As the vehicle used to deliver the product, software acts as the basis for the control of the
computer (operating systems), the communication of information (networks), andthe
creation and control of other programs (software tools and environments).
Software delivers the most important product of our time—information. It transforms
personal data so that the data can be more useful in a local context; it manages
business information to enhance competitiveness; it provides a gateway to worldwide
information networks, and provides the means for acquiring information in all of its forms.
The role of computer software has undergone significant change over the last half-
century. Dramatic improvements in hardware performance, profound changes in
computing architectures, vast increases in memory and storage capacity, and a wide
variety of exotic input and output options, have all precipitated more sophisticated and
complex computer-based systems. Sophistication and complexity can produce dazzling
results when a system succeeds, but they can also pose huge problems for those who
must build complex systems.
1.1.1 Defining Software: Software is:
(1) instructions (computer programs) that when executed provide desired features,
function, and performance;
(2) data structures that enable the programs to adequately manipulate information, and
(3) descriptive information in both hard copy and virtual forms that describes the
operation and use of the programs.
Software has characteristics that are considerably different than those of hardware:
1. Software is developed or engineered: it is not manufactured in the classical sense.
Although some similarities exist between software development and hardware
manufacturing, the two activities are fundamentally different. In both activities, high quality
is achieved through good design, but the manufacturing phase for hardware can introduce
quality problems that are nonexistent (or easily corrected) for software. Software projects
cannot be managed as if they were manufacturing projects.

2. Software doesn’t “wear out.”: Figure 1.1 depicts failure rate as a function of time
for hardware. The relationship, often called the “bathtub curve,” indicates that hardware
exhibits relatively high failure rates early in its life; defects are corrected and the failure
rate drops to a steady-state level (hopefully, quite low) for some period of time. As time
passes, however, the failure rate rises again as hardware components suffer from the
cumulative effects of dust, vibration, abuse, temperature extremes, and many other
environmental maladies.
Stated simply, the hardware begins to wear out. Software is not susceptible to the
environmental maladies that cause hardware to wear out. In theory, therefore, thefailure
rate curve for software should take the form of the “idealized curve” shown in Figure 1.2.
Undiscovered defects will cause high failure rates early in the life of a program. However,
these are corrected and the curve flattens as shown. The idealized

curve is a gross oversimplification of actual failure models for software. However, the
implication is clear—software doesn’t wear out. But it does deteriorate.
3. Although the industry is moving toward component-based construction, most
software continues to be custom built: As an engineering discipline evolves, a
collection of standard design components is created. The reusable components have
been created so that the engineer can concentrate on the truly innovative elements of a
design, that is, the parts of the design that represent something new.
A software component should be designed and implemented so that it can be reused in
many different programs. Modern reusable components encapsulate both data and the
processing that is applied to the data, enabling the software engineer to create new
applications from reusable parts.
1.1.2 Software Application Domains: Today, seven broad categories of computer
software present continuing challenges for software engineers:
System software—a collection of programs written to service other programs. Some
system software (e.g., compilers, editors, and file management utilities) processes
complex, but determinate, information structures. Other systems applications (e.g.,
operating system components, drivers, networking software, telecommunications
processors) process largely indeterminate data.
Application software—stand-alone programs that solve a specific business need.
Applications in this area process business or technical data in a way that facilitates
business operations or management/technical decision making.
Engineering/scientific software—has been characterized by “number crunching”
algorithms. Applications range from astronomy to volcanology, from automotive stress
analysis to space shuttle orbital dynamics, and from molecular biology to automated
manufacturing.
Embedded software—resides within a product or system and is used to implement and
control features and functions for the end user and for the system itself.
Product-line software—designed to provide a specific capability for use by many different
customers. Product-line software can focus on a limited and esoteric marketplace or
address mass consumer markets.
Web applications—called “WebApps,” this network-centric software category spans a
wide array of applications. In their simplest form, WebApps can be little more than a set
of linked hypertext files that present information using text and limited graphics.

Artificial intelligence software—makes use of nonnumerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis. Applications
within this area include robotics, expert systems, pattern recognition (image and voice),
artificial neural networks, theorem proving, and game playing.
New Challenges
Open-world computing—the rapid growth of wireless networking may soon lead to
true pervasive, distributed computing. The challenge for software engineers will be to
develop systems and application software that will allow mobile devices, personal
computers, and enterprise systems to communicate across vast networks.
Net sourcing—the World Wide Web is rapidly becoming a computing engine as well as
a content provider. The challenge for software engineers is to architect simple and
sophisticated applications that provide a benefit to targeted end-user marketsworldwide.
Open source—a growing trend that results in distribution of source code for systems
applications so that many people can contribute to its development.
1.1.3 Legacy Software: These older programs—often referred to as legacy software.
Legacy software systems . were developed decades ago and have been continually
modified to meet changes in business requirements and computing platforms. Legacy
software is characterized by longevity and business criticality.
Unfortunately, there is sometimes one additional characteristic that is present in legacy
software—poor quality. Legacy systems sometimes have inextensible designs, convoluted
code, poor or nonexistent documentation, test cases and results.
Legacy systems often evolve for one or more of the following reasons:
• The software must be adapted to meet the needs of new computing environments or
technology.
• The software must be enhanced to implement new business requirements.
• The software must be extended to make it interoperable with other more modern
systems or databases.
• The software must be re-architected to make it viable within a network environment.

1.2 THE UNIQUE NATURE OF WEBAPPS
The following attributes are encountered in the vast majority of WebApps.
Network intensiveness. A WebApp resides on a network and must serve the needs of
a diverse community of clients. The network may enable worldwide access and
communication (i.e., the Internet) or more limited access and communication (e.g., a
corporate Intranet).
Concurrency. A large number of users may access the WebApp at one time. In many
cases, the patterns of usage among end users will vary greatly.
Unpredictable load. The number of users of the WebApp may vary by orders of
magnitude from day to day. One hundred users may show up on Monday; 10,000 may
use the system on Thursday.
Performance. If a WebApp user must wait too long, he or she may decide to go
elsewhere.
Availability. Although expectation of 100 percent availability is unreasonable, users of
popular WebApps often demand access on a 24/7/365 basis. Users in Australia or Asia
might demand access during times when traditional domestic software applications in
North America might be taken off-line for maintenance.
Data driven. The primary function of many WebApps is to use hypermedia to present
text, graphics, audio, and video content to the end user. In addition, WebApps are
commonly used to access information that exists on databases that are not an integral
part of the Web-based environment
Content sensitive. The quality and aesthetic nature of content remains an important
determinant of the quality of a WebApp.
Continuous evolution. Unlike conventional application software that evolves over a
series of planned, chronologically spaced releases, Web applications evolve
continuously. It is not unusual for some WebApps (specifically, their content) to be
updated on a minute-by-minute schedule or for content to be independently computed for
each request.
Immediacy. Although immediacy—the compelling need to get software to market quickly—
is a characteristic of many application domains, WebApps often exhibit a time- to-market
that can be a matter of a few days or weeks.
Security. Because WebApps are available via network access, it is difficult, if not
impossible, to limit the population of end users who may access the application. In order
to protect sensitive content and provide secure modes of data transmission, strong
security measures must be implemented throughout the infrastructure that supports a
WebApp and within the application itself.
Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel. When an
application has been designed to market or sell products or ideas, aesthetics may have
as much to do with success as technical design.

1.3 SOFTWARE ENGINEERING
Software engineering encompasses a process, methods for managing and engineering
software, and tools.
In order to build software that is ready to meet the challenges of the twenty-first century,
few simple realities are:
• Software has become deeply embedded in virtually every aspect of our lives, and as a
consequence, the number of people who have an interest in the features and functions
provided by a specific application has grown dramatically.
• The information technology requirements demanded by individuals, businesses, and
governments grow increasing complex with each passing year. The complexity of these
new computer-based systems and products demands careful attention to the interactions
of all system elements. It follows that design becomes a pivotal activity.
• Individuals, businesses, and governments increasingly rely on software for strategic and
tactical decision making as well as day-to-day operations and control. If the software fails,
people and major enterprises can experience anything from minor inconvenience to
catastrophic failures.
• As the perceived value of a specific application grows, the likelihood is that its user base
and longevity will also grow. As its user base and time-in-use increase, demands for
adaptation and enhancement will also grow. It follows that software should be
maintainable.
The IEEE has developed a more comprehensive definition when it states:
Software Engineering: (1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that is, the
application of engineering to software. (2) The study of approaches as in (1).
Layered Technology: Software engineering is a layered technology. Referring to
Figure 1.3, any engineering approach (including software engineering) must rest on an

organizational commitment to quality. Total quality management, Six Sigma, and similar
philosophies foster a continuous process improvement culture, and it is this culture that
ultimately leads to the development of increasingly more effective approaches to software
engineering. The bedrock of software engineering is a quality focus.
The foundation for software engineering is the process layer. The software engineering
process is the glue that holds the technology layers together and enables rational and
timely development of computer software. Process defines a framework that must be
established for effective delivery of software engineering technology.
The software process forms the basis for management control of software projects and
establishes the context in which technical methods are applied, work products (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality
is ensured, and change is properly managed.
Software engineering methods provide the technical how-to’s for building software.
Methods encompass a broad array of tasks that include communication, requirements
analysis, design modeling, program construction, testing, and support. Software
engineering methods rely on a set of basic principles that govern each area of the
technology and include modeling activities and other descriptive techniques.
Software engineering tools provide automated or semi automated support for the process
and the methods. When tools are integrated so that information created by one tool can
be used by another, a system for the support of software development, called computer-
aided software engineering, is established.
1.4 The software Process
A process defines who is doing what when and how to reach a certain goal.
A process is a collection of activities, actions, and tasks that are performed when some
work product is to be created. An activity strives to achieve a broad objective andis
applied regardless of the application domain, size of the project, complexity of the effort,
or degree of rigor with which software engineering is to be applied. An action
encompasses a set of tasks that produce a major work product. A task focuses on a small,
but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.
A process is not a rigid rather it is an adaptable approach to choose the appropriate set
of work actions and tasks. The intent is always to deliver software in a timely manner and
with sufficient quality to satisfy those who have sponsored its creation and those who will
use it.

A process framework establishes the foundation for a complete software engineering
process by identifying a small number of framework activities that are applicable to all
software projects, regardless of their size or complexity. In addition, the process
framework encompasses a set of umbrella activities that are applicable across the entire
software process. A generic process framework for software engineering encompasses
five activities:
Communication. Before any technical work can commence, it is critically important to
communicate and collaborate with the customer. The intent is to understandstakeholders’
objectives for the project and to gather requirements that help define software features
and functions.
Planning. The planning activity creates a “map” called a software project plan—defines
the software engineering work by describing the technical tasks to be conducted, the risks
that are likely, the resources that will be required, the work products to be produced, and
a work schedule.
Modeling. You create a “sketch” of the thing so that you’ll understand the big picture. A
software engineer does the same thing by creating models to better understand software
requirements and the design that will achieve those requirements.
Construction. This activity combines code generation and the testing that is required to
uncover errors in the code.
Deployment. The software is delivered to the customer who evaluates the delivered
product and provides feedback based on the evaluation.
These five generic framework activities can be used during the development of small,
simple programs, the creation of large Web applications, and for the engineering of large,
complex computer-based systems. The details of the software process will be quite
different in each case, but the framework activities remain the same.
That is, communication, planning, modeling, construction, and deployment are applied
repeatedly through a number of project iterations. Each project iteration produces a
software increment that provides stakeholders with a subset of overall software features
and functionality.
Software engineering process framework activities are complemented by a number of
umbrella activities. In general, umbrella activities are applied throughout a software
project.
Typical umbrella activities include:
Software project tracking and control—allows the software team to assess progress
against the project plan and take any necessary action to maintain the schedule.
Risk management—assesses risks that may affect the outcome of the project or the
quality of the product.

Software quality assurance—defines and conducts the activities required to ensure
software quality.
Technical reviews—assesses software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
Measurement—defines and collects process, project, and product measures that assist
the team in delivering software that meets stakeholders’ needs; can be used in
conjunction with all other framework and umbrella activities.
Software configuration management—manages the effects of change throughout the
software process.
Reusability management—defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
Work product preparation and production—encompasses the activities required to
create work products such as models, documents, logs, forms, and lists.
1.5 Software Engineering Practice
Generic framework activities—communication, planning, modeling, construction, and
deployment—and umbrella activities establish a skeleton architecture for software
engineering work. Practices are as follows
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
Understand the problem. It’s worth spending a little time to understand, answering a
few simple questions:
• Who has a stake in the solution to the problem? That is, who are the stakeholders?
• What are the unknowns? What data, functions, and features are required to properly
solve the problem?
• Can the problem be compartmentalized? Is it possible to represent smaller problems
that may be easier to understand?
• Can the problem be represented graphically? Can an analysis model be created?
Plan the solution. Now you understand the problem and you can’t wait to begin coding.
Before you do, slow down just a bit and do a little design:
• Have you seen similar problems before? Are there patterns that are recognizable in a
potential solution? Is there existing software that implements the data, functions, and
features that are required?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can sub problems be defined? If so, are solutions readily apparent for the sub
problems?

• Can you represent a solution in a manner that leads to effective implementation? Can
a design model be created?
Plan the solution. Now you understand the problem (or so you think) and you can’t
wait to begin coding. Before you do, slow down just a bit and do a little design:
• Have you seen similar problems before? Are there patterns that are recognizable in a
potential solution? Is there existing software that implements the data, functions, and
features that are required?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can sub problems be defined? If so, are solutions readily apparent for the sub
problems?
• Can you represent a solution in a manner that leads to effective implementation? Can
a design model be created?
Examine the result. You can’t be sure that your solution is perfect, but you can be sure
that you’ve designed a sufficient number of tests to uncover as many errors as possible.
• Is it possible to test each component part of the solution? Has a reasonable testing
strategy been implemented?
• Does the solution produce results that conform to the data, functions, and features that
are required? Has the software been validated against all stakeholder requirements?
1.5.2 General Principles: David Hooker has proposed seven principles that focus on
software engineering practice as a whole. They are as following.
The First Principle: The Reason It All Exists
A software system exists for one reason: to provide value to its users. Before specifying
a system requirement, before noting a piece of system functionality, before determining
the hardware platforms or development processes, ask yourself questions such as: “Does
this add real value to the system?” If the answer is “no,” don’t do it. All other principles
support this one.
The Second Principle: KISS (Keep It Simple, Stupid!)
There are many factors to consider in any design effort. All design should be as simple as
possible, but no simpler. This facilitates having a more easily understood and easily
maintained system. Indeed, the more elegant designs are usually the more simple ones.
The payoff is software that is more maintainable and less error-prone.
The Third Principle: Maintain the Vision
A clear vision is essential to the success of a software project. Without one, a project
almost unfailingly ends up. Compromising the architectural vision of a software system
weakens and will eventually break even the well-designed systems. Having an
empowered architect who can hold the vision and enforce compliance helps ensure a very
successful software project.
The Fourth Principle: What You Produce, Others Will Consume

Design, keeping the implementers in mind. Code with concern for those that must
maintain and extend the system. Someone may have to debug the code you write, and
that makes them a user of your code. Making their job easier adds value to the system.
The Fifth Principle: Be Open to the Future
A system with a long lifetime has more value. Never design yourself into a corner. Always
ask “what if,” and prepare for all possible answers by creating systems that solve the
general problem, not just the specific one. This could very possibly lead to the reuse of
an entire system.
The Sixth Principle: Plan Ahead for Reuse
Planning ahead for reuse reduces the cost and increases the value of both the reusable
components and the systems into which they are incorporated.
The Seventh principle: Think!
This last principle is probably the most overlooked. Placing clear, complete thought before
action almost always produces better results. When you think about something, you are
more likely to do it right.
1.6 Software myths
Today, most knowledgeable software engineering professionals recognize myths for
what they are—misleading attitudes that have caused serious problems for managers and
practitioners alike. However, old attitudes and habits are difficult to modify, and remnants
of software myths remain.
Management myths. Managers with software responsibility, like managers in most
disciplines, are often under pressure to maintain budgets, keep schedules from slipping,
and improve quality. Like a drowning person who grasps at a straw, a software manager
often grasps at belief in a software myth, if that belief will lessen the pressure.
Myth: We already have a book that’s full of standards and procedures for building
software. Won’t that provide my people with everything they need to know?
Reality: The book of standards may very well exist, but is it used? Are software
practitioners aware of its existence? Does it reflect modern software engineering
practice? Is it complete? Is it adaptable? Is it streamlined to improve time-to-delivery while
still maintaining a focus on quality? In many cases, the answer to all of these questions is
“no.”
Myth: If we get behind schedule, we can add more programmers and catch up
Reality: Software development is not a mechanistic process like manufacturing. In the
words of Brooks “adding people to a late software project makes it later.” At first, this
statement may seem counterintuitive. However, as new people are added, people who
were working must spend time educating the newcomers, thereby reducing the amount of
time spent on productive development effort. People can be added but only in a planned
and well coordinated manner.

Myth: If I decide to outsource the software project to a third party, I can just relax and let
that firm build it.
Reality: If an organization does not understand how to manage and control software
projects internally, it will invariably struggle when it outsources software projects.
Customer myths. A customer who requests computer software may be a person at the
next desk, a technical group down the hall, the marketing/sales department, or an
outside company that has requested software under contract. In many cases, the
customer believes myths about software because software managers and practitioners
do little to correct misinformation. Myths lead to false expectations and, ultimately,
dissatisfaction with the developer.
Myth: A general statement of objectives is sufficient to begin writing programs—we can
fill in the details later.
Reality: Although a comprehensive and stable statement of requirements is not always
possible, an ambiguous “statement of objectives” is a recipe for disaster. Unambiguous
requirements are developed only through effective and continuous communication
between customer and developer.
Myth: Software requirements continually change, but change can be easily
accommodated because software is flexible.
Reality: It is true that software requirements change, but the impact of change varies with
the time at which it is introduced. When requirements changes are requested early the
cost impact is relatively small.16 However, as time passes, the cost impact grows rapidly—
resources have been committed, a design framework has been established, and change
can cause upheaval that requires additional resources and major design modification.
Practitioner’s myths. Myths that are still believed by software practitioners have been
fostered by over 50 years of programming culture. During the early days, programming
was viewed as an art form. Old ways and attitudes die hard.
Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that “the sooner you begin ‘writing code,’ the longer it’ll take
you to get done.” Industry data indicate that between 60 and 80 percent of all effort
expended on software will be expended after it is delivered to the customer for the first
time.
Myth: Until I get the program “running” I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be applied
from the inception of a project—the technical review. Software are a “quality filter” that
have been found to be more effective than testing for finding certain classes of software
defects.
Myth: The only deliverable work product for a successful project is the working program.

Reality: A working program is only one part of a software configuration that includes many
elements. A variety of work products provide a foundation for successful engineering and,
more important, guidance for software support.
Myth: Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating a
quality product. Better quality leads to reduced rework. And reduced rework results in
faster delivery times.
PROCESS MODELS
1.7 A GENERIC PROCESS MODEL
The software process is represented schematically. Framework activity is populated by
a set of software engineering actions. Each software engineering action is defined by a
task set that identifies the work tasks that are to be completed, the work products that will
be produced, the quality assurance points that will be required, and the milestones that
will be used to indicate progress.
What is it? When you work to build a product or system, it’s important to go through
a series of predictable steps—a road map that helps you create a timely, high-quality
result. The road map that you follow is called a “software process.”
Who does it? Software engineers and their managers adapt the process to their needs
and then follow it. In addition, the people who have requested the software have a role
to play in the process of defining, building, and testing it.
Why is it important? Because it provides stability, control, and organization to an
activity that can, if left uncontrolled, become quite chaotic. However, a modern software
engineering approach must be “agile.” It must demand only those activities, controls,
and work products that are appropriate for the project team and the product that is to
be produced.
What are the steps? At a detailed level, the process that you adopt depends on the
software that you’re building. One process might be appropriate for creating software
for an aircraft avionics system, while an entirely different process would be indicated
for the creation of a website.
What is the work product? From the point of view of a software engineer, the work
products are the programs, documents, and data that are produced as a consequence
of the activities and tasks defined by the process.

Generic process framework for software engineering defines five framework activities—
communication, planning, modeling, construction, and deployment. In addition, a set of
umbrella activities—project tracking and control, risk management, quality assurance,
configuration management, technical reviews, and others—are applied throughout the
process.
Process flow—describes how the framework activities and the actions and tasks that occur
within each framework activity are organized with respect to sequence and time and is
illustrated in Figure 2.2.
A linear process flow executes each of the five framework activities in sequence,
beginning with communication and culminating with deployment (Figure 2.2a). An
iterative process flow repeats one or more of the activities before proceeding to the next
(Figure 2.2b). An evolutionary process flow executes the activities in a “circular” manner.
Each circuit through the five activities leads to a more complete version of the software
(Figure 2.2c). A parallel process flow (Figure 2.2d) executes one or more activities in
parallel with other activities.

1.7.1 Defining a Framework Activity: A software team would need significantly more
information before it could properly execute any one of these five activities
(Communication, Planning, Modeling, Construction, Deployment) as part of the software
process. For a small software project requested by one person (at a remote location) with
simple, straightforward requirements, the communication activity might encompass little
more than a phone call with the appropriate stakeholder. Therefore, the onlynecessary
action is phone conversation, and the work tasks (the task set) that this action
encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.
If the project was considerably more complex with many stakeholders, each with
a different set of requirements, the communication activity might have six distinct actions:
inception, elicitation, elaboration, negotiation, specification, and validation. Each
of these software engineering actions would have many work tasks and a number of
distinct work products.

1.7.2 Identifying a Task Set: Each software engineering action can be represented by
a number of different task sets—each a collection of software engineering work tasks,
related work products, quality assurance points, and project milestones. You should
choose a task set that best accommodates the needs of the project and the characteristics
of your team.
1.7.3 Process Patterns
A process pattern describes a process-related problem that is encountered during
software engineering work, identifies the environment in which the problem has been
encountered, and suggests one or more proven solutions to the problem. Stated in more
general terms, a process pattern provides you with a template. Ambler has proposed a
template for describing a process pattern:
Pattern Name. The pattern is given a meaningful name describing it within the context
of the software process
Type. The pattern type is specified. They are three types:
1. Stage pattern—defines a problem associated with a framework activity for the
process.
2. Task pattern—defines a problem associated with a software engineering action or
work task and relevant to successful software engineering practice
3. Phase pattern—define the sequence of framework activities that occurs within the
process, even when the overall flow of activities is iterative in nature.
Initial context. Describes the conditions under which the pattern applies.
Problem. The specific problem to be solved by the pattern.
Solution. Describes how to implement the pattern successfully.
Resulting Context. Describes the conditions that will result once the pattern has been
successfully implemented. Upon completion of the pattern.
Related Patterns. Provide a list of all process patterns that are directly related to this
one.
Known Uses and Examples. Indicate the specific instances in which the pattern is
applicable.
1.8 PROCESS ASSESSMENT AND IMPROVEMENT
A number of different approaches to software process assessment and improvement have
been proposed.
Standard CMMI Assessment Method for Process Improvement (SCAMPI)—provides
a five-step process assessment model that incorporates five phases: initiating,
diagnosing, establishing, acting, and learning. The SCAMPI method uses the SEI CMMI
as the basis for assessment.

CMM-Based Appraisal for Internal Process Improvement (CBA IPI)— provides a
diagnostic technique for assessing the relative maturity of a software organization; uses
the SEI CMM as the basis for the assessment.
SPICE (ISO/IEC15504)—a standard that defines a set of requirements for software
process assessment. The intent of the standard is to assist organizations in developing
an objective evaluation of the efficacy of any defined software process.
ISO 9001:2000 for Software—a generic standard that applies to any organization that
wants to improve the overall quality of the products, systems, or services that it provides.
Therefore, the standard is directly applicable to software organizations and companies.
1.9 PRESCRIPTIVE PROCESS MODELS
Prescriptive process models define a prescribed set of process elements and a
predictable process work flow. Prescriptive process models were originally proposed to
bring order to the chaos of software development.
All software process models can accommodate the generic framework activities, but each
applies a different emphasis to these activities and defines a process flow that invokes
each framework activity in a different manner.
1.9.1 The Waterfall Model: There are times when the requirements for a problem are
well understood—when work flows from communication through deployment in a
reasonably linear fashion. The waterfall model, sometimes called the classic life cycle,
suggests a systematic, sequential approach6 to software development that begins with
customer specification of requirements and progresses through planning, modeling,
construction, and deployment, culminating in ongoing support of the completed software
(Figure 2.3).
A variation in the representation of the waterfall model is called the V-model.
Represented in Figure 2.4, the V-model depicts the relationship of quality assurance

actions to the actions associated with communication, modeling, and early construction
activities. As a software team moves down the left side of the V, basic problem
requirements are refined into progressively more detailed and technical representations
of the problem and its solution. Once code has been generated, the team moves up the
right side of the V, essentially performing a series of tests (quality assurance actions) that
validate each of the models created as the team moved down the left side.7 In reality,
there is no fundamental difference between the classic life cycle and the V- model. The
V-model provides a way of visualizing how verification and validation actions are applied
to earlier engineering work.
The waterfall model is the oldest paradigm, the problems that are sometimes encountered
when the waterfall model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes. Although the
linear model can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The waterfall
model requires this and has difficulty accommodating the natural uncertainty that exists
at the beginning of many projects.

3. The customer must have patience. A working version of the program(s) will not be
available until late in the project time span. A major blunder, if undetected until the working
program is reviewed, can be disastrous.
1.9.2 Incremental Process Models: The incremental model delivers a series of
releases, called increments, that provide progressively more functionality for the
customer as each increment is delivered.
There are many situations in which initial software requirements are reasonably well
defined, but the overall scope of the development effort precludes a purely linear process.
In addition, there may be a compelling need to provide a limited set of software
functionality to users quickly and then refine and expand on that functionality in later
software releases. In such cases, you can choose a process model that is designed to
produce the software in increments.
The incremental model combines elements of linear and parallel process flows.
Referring to Figure 2.5, the incremental model applies linear sequences in a staggered
fashion as calendar time progresses. Each linear sequence produces deliverable
“increments” of the software in a manner that is similar to the increments produced by
an evolutionary process flow.
When an incremental model is used, the first increment is often a core product. That is,
basic requirements are addressed but many supplementary features remain undelivered.
The core product is used by the customer. As a result of use and/or evaluation, a plan is
developed for the next increment. The plan addresses the modification of the core
product to better meet the needs of the customer and the

delivery of additional features and functionality. This process is repeated following the
delivery of each increment, until the complete product is produced.
The incremental process model focuses on the delivery of an operational product with
each increment. Early increments are stripped-down versions of the final product, but they
do provide capability that serves the user and also provide a platform for evaluationby the
user. Incremental development is particularly useful when staffing is unavailable for a
complete implementation by the business deadline that has been established for the
project.
1.9.3 Evolutionary Process Models: Evolutionary process models produce an
increasingly more complete version of the software with each iteration.
Software, like all complex systems, evolves over a period of time. Business and product
requirements often change as development proceeds, making a straight line path to an
end product unrealistic; tight market deadlines make completion of a comprehensive
software product impossible, but a limited version must be introduced to meet
competitive or business pressure.
.
Evolutionary models are iterative. They are characterized in a manner that enables you
to develop increasingly more complete versions of the software. The two common
evolutionary process models are presented here.
Prototyping: Often, a customer defines a set of general objectives for software, but does
not identify detailed requirements for functions and features. In other cases, the developer
may be unsure of the efficiency of an algorithm, the adaptability of an operating system,
or the form that human-machine interaction should take. In these,and many other
situations, a prototyping paradigm may offer the best approach.
Regardless of the manner in which it is applied, the prototyping paradigm assists you and
other stakeholders to better understand what is to be built when requirements are fuzzy.
The prototyping paradigm (Figure 2.6) begins with communication. You meet with other
stakeholders to define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further definition is mandatory. A
Prototyping iteration is planned quickly, and modeling occurs. A quick design focuses
on a representation of those aspects of the software that will be visible to end users.
The quick design leads to the construction of a prototype. The prototype is deployed
and evaluated by stakeholders, who provide feedback that is used to further refine
requirements. Iteration occurs as the prototype is tuned to satisfy the needs of various

stakeholders, while at the same time enabling you to better understand what needs to be
done.
Prototyping can be problematic for the following reasons:
1. Stakeholders see what appears to be a working version of the software, unaware that
there is pending work.
2. As a software engineer, you often make implementation compromises in order to get
a prototype working quickly.
The Spiral Model. Originally proposed by Barry Boehm, the spiral model is an
evolutionary software process model that couples the iterative nature of prototyping with
the controlled and systematic aspects of the waterfall model. Boehm describes the model
in the following manner:
The spiral development model is a risk-driven process model generator that is used to
guide multi-stakeholder concurrent engineering of software intensive systems. It has
two main distinguishing features. One is a cyclic approach for incrementally growing a
system’s degree of definition and implementation while decreasing its degree of risk. The
other is a set of anchor point milestones for ensuring stakeholder commitment to feasible
and mutually satisfactory system solutions.
Using the spiral model, software is developed in a series of evolutionary releases. During
early iterations, the release might be a model or prototype. During later iterations,
increasingly more complete versions of the engineered system are produced.

A spiral model is divided into a set of framework activities defined by the software
engineering team. Each of the framework activities represent one segment of the spiral
path illustrated in Figure 2.7.
As this evolutionary process begins, the software team performs activities that are implied
by a circuit around the spiral in a clockwise direction, beginning at the center. Risk is
considered as each revolution is made. Anchor point milestones—a combination of work
products and conditions that are attained along the path of the spiral—are noted for each
evolutionary pass.
The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a prototype
and then progressively more sophisticated versions of the software. Each pass through
the planning region results in adjustments to the project plan. Cost and schedule are
adjusted based on feedback derived from the customer after delivery. In addition, the
project manager adjusts the planned number of iterations required to complete the
software.
Unlike other process models that end when software is delivered, the spiral model can be
adapted to apply throughout the life of the computer software. The spiral model is a
realistic approach to the development of large-scale systems and software. Because
software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level.
1.9.4 Concurrent Models: The concurrent development model, sometimes called
concurrent engineering, allows a software team to represent iterative and concurrent
elements of any of the process models. Figure 2.8 provides a schematic representation

of one software engineering activity within the modeling activity using a concurrent
modeling approach. The activity—modeling—may be in any one of the states noted at
any given time. Similarly,
other activities, actions, or tasks (e.g., communication or construction) can be represented
in an analogous manner. All software engineering activities exist concurrently but reside
in different states.
Concurrent modeling defines a series of events that will trigger transitions from state to
state for each of the software engineering activities, actions, or tasks. For example, during
early stages of design, an inconsistency in the requirements model is uncovered. This
generates the event analysis model correction, which will trigger the requirements
analysis action from the done state into the awaiting changes state. Concurrent odeling is
applicable to all types of software development and provides an accurate picture of the
current state of a project.

1.10 SPECIALIZED PROCESS MODELS
These models tend to be applied when a specialized or narrowly defined software
engineering approach is chosen.
1.10.1 Component-Based Development: Commercial off-the-shelf (COTS) software
components, developed by vendors who offer them as products, provide targeted
functionality with well-defined interfaces that enable the component to be integrated into
the software that is to be built. The component-based development model incorporates
many of the characteristics of the spiral model. It is evolutionary in nature, demanding an
iterative approach to the creation of software. However, the component-based
development model constructs applications from prepackaged software components.
Modeling and construction activities begin with the identification of candidate
components. These components can be designed as either conventional software
modules or object-oriented classes or packages of classes. Regardless of the technology
that is used to create the components, the component-based development model
incorporates the following steps
1. Available component-based products are researched and evaluated for the
application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
The component-based development model leads to software reuse, and reusability
provides software engineers with a number of measurable benefits.
1.10.2 The Formal Methods Model: The formal methods model encompasses a set of
activities that leads to formal mathematical specification of computer software. Formal
methods enable you to specify, develop, and verify a computer-based system by applying
a rigorous, mathematical notation. A variation on this approach, called cleanroom
software engineering, is currently applied by some software development organizations.
When formal methods are used during design, they serve as a basis for program
verification and therefore enable you to discover and correct errors that might otherwise
go undetected.

Although not a mainstream approach, the formal methods model offers the promise of
defect-free software. Yet, concern about its applicability in a business environment has
been voiced:
• The development of formal models is currently quite time consuming and
expensive.
• Because few software developers have the necessary background to apply
formal methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
1.10.3 Aspect-Oriented Software Development:Regardless of the software process
that is chosen, the builders of complex software invariably implement a set of localized
features, functions, and information content. These localized software characteristics are
modeled as components (e.g., object oriented classes) and then constructed within the
context of a system architecture.
As modern computer-based systems become more sophisticated (and complex), Other
concerns affect functions (e.g., the application of business rules), while others are
systemic (e.g., task synchronization or memory management).
When concerns cut across multiple system functions, features, and information, they
are often referred to as crosscutting concerns. Aspectual requirements define those
crosscutting concerns that have an impact across the software architecture. Aspect-
oriented software development (AOSD), often referred to as aspect-oriented
programming (AOP), is a relatively new software engineering paradigm that provides a
process and methodological approach for defining, specifying, designing, and
constructing aspects.
AOCE uses a concept of horizontal slices through vertically-decomposed software
components, called “aspects,” to characterize cross-cutting functional and non- functional
properties of components. Common, systemic aspects include user interfaces,
collaborative work, distribution, persistency, memory management, transaction
processing, security, integrity and so on.
1.11 The UNIFIED PROCESS
1.11.1 Introduction: The Unified Process is an attempt to draw on the best features and
characteristics of traditional software process models, but haracterize them in away
that implements many of the best principles of agile software development.
The Unified Process recognizes the importance of customer communication and
streamlined methods for describing the customer’s view of a system. It emphasizes the

important role of software architecture and “helps the architect focus on the right goals,
such as understandability, reliance to future changes, and reuse”.
1.11.2 Phases of the Unified Process: The Unified Process is with five basic framework
activities depicted in figure 2.9. It depicts the “phases” of the UP and relates them to the
generic activities.
The inception phase of the UP encompasses both customer communication and planning
activities. The elaboration phase encompasses the communication and modeling
activities of the generic process model. The construction phase of the UP is identical to
the construction activity defined for the generic software process. The transition phase of
the UP encompasses the latter stages of the generic construction activity and the first part
of the generic deployment (delivery and feedback) activity. Software is given to end users
for beta testing and user feedback reports both defects and necessary changes. In
addition, the software team creates the necessary support information (e.g., user
manuals, troubleshooting guides, installation procedures) that is required for the release.
The production phase of the UP coincides with the deployment activity of the generic
process. During this phase, the ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and defect reports and requests for
changes are submitted and evaluated. A software engineering workflow is distributed
across all UP phases.
1.12 PERSONAL AND TEAM PROCESS MODELS
1.12.1 Introduction: If a software process model has been developed at a corporate or
organizational level, it can be effective only if it is agreeable to significant adaptation to
meet the needs of the project team that is actually doing software engineering work. In

an ideal setting, you would create a process that best fits your needs, and at the same
time, meets the broader needs of the team and the organization. Alternatively, the team
itself can create its own process, and at the same time meet the narrower needs of
individuals and the broader needs of the organization.
1.12.2 Personal Software Process (PSP): Every developer uses some process to build
computer software. The Personal Software Process (PSP) emphasizes personal
measurement of both the work product that is produced and the resultant quality of the
work product. In addition PSP makes the practitioner responsible for project planning
(e.g., estimating and scheduling) and empowers the practitioner to control the quality of
all software work products that are developed. The PSP model defines five framework
activities:
Planning. This activity isolates requirements and develops both size and resource
estimates. In addition, a defect estimate is made. All metrics are recorded on worksheets
or templates. Finally, development tasks are identified and a project schedule is created.
High-level design. External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty
exists. All issues are recorded and tracked.
High-level design review. Formal verification methods are applied to uncover errors in
the design. Metrics are maintained for all important tasks and work results.
Development. The component-level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
Postmortem. Using the measures and metrics collected, the effectiveness of the process
is determined. Measures and metrics should provide guidance for modifying theprocess
to improve its effectiveness.
PSP emphasizes the need to record and analyze the types of errors you make, so that
you can develop strategies to eliminate them.
1.12.3 Team Software Process (TSP): Because many industry-grade software projects
are addressed by a team of practitioners, The goal of TSP is to build a “self-directed”
project team that organizes itself to produce high-quality software.
Humphrey defines the following objectives for TSP:
• Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams
(IPTs) of 3 to about 20 engineers.
• Show managers how to coach and motivate their teams and how to help them sustain
peak performance.
• Accelerate software process improvement by making CMM Level 5 behavior normal and
expected.

• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.
A self-directed team has a consistent understanding of its overall goals and objectives;
defines roles and responsibilities for each team member; tracks quantitative project data
identifies a team process that is appropriate for the project and a strategy for
implementing the process; defines local standards that are applicable to the team’s
software engineering work; continually assesses risk and reacts to it; and tracks,
manages, and reports project status.
TSP defines the following framework activities: project launch, high-level design,
implementation, integration and test, and postmortem.
TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team
members in their work. TSP recognizes that the best software teams are self- directed.
Team members set project objectives, adapt the process to meet their needs, control the
project schedule, and through measurement and analysis of the metrics collected, work
continually to improve the team’s approach to software engineering.
1.13 PROCESS TECHNOLOGY
Process technology tools allow a software organization to build an automated model of
the process framework, task sets, and umbrella activities. The model, normally
represented as a network, can then be analyzed to determine typical workflow and
examine alternative process structures that might lead to reduced development time or
cost.
Once an acceptable process has been created, other process technology tools can be
used to allocate, monitor, and even control all software engineering activities, actions, and
tasks defined as part of the process model. Each member of a software team can use
such tools to develop a checklist of work tasks to be performed, work products to be
produced, and quality assurance activities to be conducted. The process technology
tool can also be used to coordinate the use of other software engineering tools that are
appropriate for a particular work task.
1.14 PRODUCT AND PROCESS
If the process is weak, the end product will undoubtedly suffer. All of human activity may
be a Process. And the outcome of the process is Product.

Software is more than just a program code. Software engineering isan
engineering branch associated with development of software product using well-defined
scientific principles, methods and procedures which is process. The outcome of
software engineering is an efficient and reliable software product.
About every ten years give or take five, the software community redefines “the problem”
by shifting its focus from product issues to process issues. Thus, we have embraced
structured programming languages (product) followed by structured analysis methods
(process) followed by data encapsulation (product) followed by the current emphasis on
the Software Engineering Institute’s Software Development Capability Maturity Model
(process)
People: The primary element of any project is the people. People gather requirements,
people interview users (people), people design software, and people write software for
people. No people -- no software.
Process: Process is how we go from the beginning to the end of a project. All projects
use a process. Many project managers, however, do not choose a process based on
the people and product at hand. They simply use the same process they've always used
or misused. Let's focus on two points regarding process: (1) process improvement and
(2) using the right process for the people and product at hand.

Product: The product is the result of a project. The desired product satisfies the
customers and keeps them coming back for more. Sometimes, however, the actual
product is something less.
The product pays the bills and ultimately allows people to work together in a process
and build software. Always keep the product in focus. Our current emphasis on process
sometimes causes us to forget the product. This results in a poor product, no money, no
more business, and no more need for people and process.
1.15 WHAT IS AGILITY?
AGILITY
An agile team is a nimble team able to appropriately respond to changes. Change is what
software development is very much about. Changes in the software being built, changes
to the team members, changes because of new technology, changes of all kinds that may
have an impact on the product they build or the project that creates the product. Support
for changes should be built-in everything we do in software, something we embrace
because it is the heart and soul of software. An agile team recognizes that software is
developed by individuals working in teams and that the skills of thesepeople, their ability
to collaborate is at the core for the success of the project.
It encourages team structures and attitudes that make communication (among team
members, between technologists and business people, between software engineers
and their managers) more facile. It emphasizes rapid delivery of operational software and
de-emphasizes the importance of intermediate work products.
Agility can be applied to any software process. However, to accomplish this, it is essential
that the process be designed in a way that allows the project team to adapt tasks and to
streamline them, conduct planning in a way that understands the fluidity of an agile
development approach, eliminate all but the most essential work products and keep them
lean, and emphasize an incremental delivery strategy that gets working software to the
customer as rapidly as feasible for the product type and operational environment.
1.16 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: solid black curve). 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.
The change requires a modification to the architectural design of the software, the design
and construction of three new components, modifications to another five components, the
design of new tests, and so on. Costs escalate quickly, and the time and cost required to
ensure that the change is made without unintended side effects is nontrivial. Although
debate about the degree to which the cost curve flattens is ongoing, there is evidence
to suggest that a significant reduction in the cost of change can be achieved.
1.17 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. 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 as we might like.
Given these three assumptions, an important question arises: How do we create a
process that can manage unpredictability? The answer, as I have already noted, lies in
process adaptability. An agile process, therefore, must be adaptable. But continual
adaptation without forward progress accomplishes little. Therefore, 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 instituted. Software increments must be delivered in short time periods
so that adaptation keeps pace with change. This iterative approach enables the customer
to evaluate the software increment regularly, provide necessary feedback to the software
team, and influence the process adaptations that are made to accommodate the
feedback.
1.17.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 environment and support
they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
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.
1.17.2 The Politics of Agile Development: There is considerable debate about the
benefits and applicability of agile software development as opposed to moreconventional
software engineering processes. No one is against agility. The real question is: What is
the best way to achieve it? As important, how do you build software that meets customers’
needs today and exhibits the quality characteristics that will enable it to be extended and
scaled to meet customers’ needs over the long term?
There are no absolute answers to either of these questions. Even within the agile school
itself, there are many proposed process models, each with a subtly different approach
to the agility problem. Within each model there is a set of “ideas” that represent a

significant departure from traditional software engineering. And yet, many agile concepts
are simply adaptations of good software engineering concepts. Bottom line: there is much
that can be gained by considering the best of both schools and virtually nothing to be
gained by denigrating either approach.
1.17.3 Human Factors: Proponents of agile software development take great pains to
emphasize the importance of “people factors.” If members of the software team are to
drive the characteristics of the process that is applied to build software, a number of key
traits must exist among the people on an agile team and the team itself:
Competence: In an agile development (as well as software engineering) 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 members.
Common focus:. Although members of the agile team may perform different tasks and
bring different skills to the project, all should be focused on one goal—to deliver a working
software increment to the customer within the time promised. To achieve this goal, the
team will also focus on continual adaptations (small and large) that will make the process
fit the needs of the team.
Collaboration: Software engineerinG is about assessing, 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 that provides
business value for the customer. To accomplish these tasks, team members must
collaborate—with one another and all other stakeholders.
Decision-making ability. Any good software team must be allowed the freedom to
control its own destiny. This implies that the team is given autonomy—decision-making
authority for both technical and project issues.
Fuzzy problem-solving ability. Software managers must recognize that the agile team
will continually have to deal with ambiguity and will continually be buffeted by change. In
some cases, the team must accept the fact that the problem they are solving today may
not be the problem that needs to be solved tomorrow. However, lessons learned from any
problem-solving. activity (including those that solve the wrong problem) may be of benefit
to the team later in the project.
Mutual trust and respect. The agile team must become what DeMarco and Lister call
a “jelled” team. A jelled team exhibits the trust and respect that are necessary to make
them “so strongly knit that the whole is greater than the sum of the parts.”
Self-organization. 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. In essence, the team serves as its own management.

1.18 EXTREME PROGRAMMING (XP)
Extreme Programming (XP), the most widely used approach to agile software
development.
1.18.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, actions, and
tasks.
Communication: In order to achieve effective communication between software
engineers and other stakeholders (e.g., to establish required features and functions for
the software), XP emphasizes close, yet informal (verbal) collaboration between
customers and developers, the establishment of effective metaphors for communicating
important concepts, continuous feedback, and the avoidance of voluminous
documentation as a communication medium.
Simplicity: To achieve simplicity, XP restricts developers to design only for immediate
needs, rather than consider future needs. The intent is to create a simple design that
can be easily implemented in code. If the design must be improved, it can be refactored
at a later time.
Feedback: It is derived from three sources: the implemented software itself, the
customer, and other software team members. By designing and implementing an effective
testing strategy, the software provides the agile team with feedback The degree to which
the software implements the output, function, and behavior of the use case is a form of
feedback. 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: 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.
Respect: By following each of these values, the agile team inculcates respect among
its members, between other stakeholders and team members, and indirectly, for the
software itself. As they achieve successful delivery of software increments, the team
develops growing respect for the XP process.
1.18.2 The XP Process: Extreme Programming uses an object-oriented approach as its
preferred development paradigm and encompasses a set of rules and practices that occur
within the context of four framework activities: planning, design, coding, and testing.
Figure 3.2 illustrates the XP process .
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 and to get a broad feel for required output and major features and
functionality.
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, nothingmore. If a
difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that portion of the
design. Called a spike solution, the design prototype is implemented and evaluated. 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. In fact,
the construction activity itself will provide the XP team with guidance on how to improve
the design.
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. Nothing extraneous is added (KIS). 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. XP recommends that two
people work together at one computer workstation to create code for a story. Problem
solving (two heads are often better than one) and real-time quality assurance.
Testing: I have already noted that 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. As the individual unit tests are
organized into a “universal testing suite”.
integration and validation testing of the system can occur on a daily basis. 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.
1.18.3 Industrial XP: IXP is an organic evolution of XP. It is imbued with XP’s minimalist,
customer-centric, test-driven spirit. IXP incorporates six new practices that are designed
to help ensure that an XP project works successfully for significant projects within a large
organization.
Readiness assessment: Prior to the initiation of an IXP project, the organization should
conduct a readiness assessment. The assessment ascertains whether (1) an appropriate
development environment exists to support IXP, (2) the team will be populated by the
proper set of stakeholders, (3) the organization has a distinct quality program and
supports continuous improvement, (4) the organizational culture will support the new
values of an agile team, and (5) the broader project community will be populated
appropriately.
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 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. Acommunity may have
a technologist and customers who are central to the success of a project as well as many
other stakeholders (e.g., legal staff, quality auditors, manufacturing or sales types) who
“are often at the periphery of an IXP project yet they may play important roles on the
project”. In IXP, the community members and their rolesshould be explicitly defined and
mechanisms for communication and coordination between community members should
be established.
Project chartering. The IXP team assesses the project itself to determine whether an
appropriate business justification for the project exists and whether the project will further
the overall goals and objectives of the organization. Chartering also examines the context
of the project to determine how it complements, extends, or replaces existing systems
or processes.
Test-driven management. An IXP project requires measurable criteria for assessing the
state of the project and the progress that has been made to date. Test-driven
management establishes a series of measurable “destinations” and then defines
mechanisms for determining whether or not these destinations have been reached.
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.
1.18.4 The XP Debate: 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.
• 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. 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. Proponents counter that the changing nature of
requirements makes such models and specification obsolete almost as soon as they are
developed.
• 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.
1.19 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 theindustry.
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.19.1 Adaptive Software Development (ASD): Adaptive Software Development
(ASD) has been proposed by Jim Highsmith as a technique for building complex software
and systems. The philosophical underpinnings of ASD focus on human collaboration and
team self-organization.

1.19.2 Scrum: Scrum is an agile software development method that was conceived by
Jeff Sutherland in the early 1990s. Scrum principles are consistent with the agile
manifesto and are used to guide development activities within a process that incorporates
the following framework activities: requirements, analysis, design, evolution, and
delivery. Within each framework activity, work tasks occur within a process pattern called
a sprint. The work conducted within a sprint is adapted to the problem at hand and is
defined and often modified in real time by the Scrum team. The overall flow of the Scrum
process is illustrated in Figure

Scrum emphasizes the use of a set of software process patterns that have proven
effective for 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. 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.
Changes (e.g., backlog work items) are not introduced during the sprint. Hence, the sprint
allows team members to work in a short-term, but stable environment.
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?
A 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. Also, these daily meetings lead to “knowledge socialization” and
thereby promote a self-organizing team structure.
Demos—deliver the software increment to the customer so that functionality that has been
implemented can be demonstrated and evaluated by the customer. It is important to note
that the demo may not contain all planned functionality, but rather those functions that
can be delivered within the time-box that was established.
1.19.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 timeconstraints
through the use of incremental prototyping in a controlled projectenvironment”. 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. That is, only enough work is required for each increment to facilitate movement to
the next increment. The remaining detail can be completed later when more business
requirements are known or changes have been requested and accommodated.
DSDM consortium has defined an agile process model, called the 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 and then assesses whether the application is
a viable candidate for the DSDM process.

Business study—establishes the functional and information requirements that will allow
the application to provide business value; also, 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 during this iterative cycle 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 in a manner that will enable it to 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 completeor (2) changes
may be requested as the increment is put into place. In either case, DSDM development
work continues by returning to the functional model iteration activity.
1.19.4 Crystal: To achieve maneuverability, Cockburn and Highsmith have defined a set
of methodologies, each with core elements that are common to all, and roles,
process patterns, work products, and practice that are unique to each. 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 project and environment.
1.19.5 Feature Driven Development (FDD): 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, the use of design and
code inspections, the application of software quality assurance audits, the collection of
metrics, and the use of patterns
In the context of FDD, a feature “is a client-valued function that can be implemented in
two weeks or less”. The emphasis on the definition of 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.
1.19.6 Lean Software Development (LSD): The lean principles that inspire the LSD
process can be summarized as eliminate waste, build quality in, create knowledge, defer
commitment, deliver fast, respect people, and optimize the whole. Each of these
principles can be adapted to the software process. For example, eliminate waste within
the context of an agile software project can be interpreted to mean (1) adding no
extraneous features or functions, (2) assessing the cost and schedule impact of any newly
requested requirement, (3) removing any superfluous process steps, (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.
1.19.7 Agile Modeling (AM): There are many situations in which software engineers
must build large, business critical systems. The scope and complexity of such systems
must be modeled so that (1) all constituencies can better understand what needs to be
accomplished, (2) the problem can be partitioned effectively among the people whomust
solve it, and (3) quality can be assessed as the system is being engineered and built.
Agile modeling adopts all of the values that are consistent with the agile manifesto. 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 re factor. The team must also

have the humility to recognize that technologists do not have all the answers and that
business expert and other stakeholders should be respected and embraced. Although AM
suggests a wide array of “core” and “supplementary” modeling principles, those that make
AM unique are:
• Model with a purpose
• Use multiple models
• Travel light
• Content is more important than representation
• Know the models and the tools you use to create them
• Adapt locally
1.19.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.
By adopting the classic UP phased activities—inception, elaboration, construction, and
transition—AUP provides a serial overlay that enables a team to visualize the overall
process flow for a software project. However, within each of the activities, the team
iterates to achieve agility and to deliver meaningful software increments to end users as
rapidly as possible. Each AUP iteration addresses the following activities
• Modeling. UML representations of the business and problem domains are created.
However, to stay agile, these models should be “just barely good enough” to allow the
team to proceed.
• 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. Like the generic process activity. Deployment in this context 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. Project management tracks and
controls the progress of the team and coordinates team activities.
• Environment management. Environment management coordinates a process
infrastructure that includes standards, tools, and other support technology available to the
team.

UNIT – 2
2.0 UNDERSTANDING REQUIREMENTS
What is it? Before you begin any technical work, it’s a good idea to apply a set of
requirements engineering tasks. These tasks lead to an understanding of what the business
impact of the software will be, what the customer wants, and how end users will interact with
the software.
Who does it? Software engineers (sometimes referred to as system engineers or “analysts”
in the IT world) and other project stakeholders (managers, customers, end users) all
participate in requirements engineering.
Why is it important? Designing and building an elegant computer program that solves the
wrong problem serves no one’s needs. That’s why it’s important to understand what the
customer wants before you begin to design and build a computer-based system.
What are the steps? Requirements engineering begins with inception—a task that
defines the scope and nature of the problem to be solved. It moves onwards to
elicitation—a task that helps stakeholders define what is required, and then elaboration—
where basic requirements are refined and modified. As stakeholders definethe problem,
negotiation occurs—what are the priorities, what is essential, when is itrequired? Finally,
the problem is specified in some manner and then reviewed or validatedto ensure that
your understanding of the problem and the stakeholders’ understanding ofthe problem
coincide.
What is the work product? The intent of requirements engineering is to provide all parties
with a written understanding of the problem. This can be achieved though anumber of work
products: usage scenarios, functions and features lists, requirements models, or a
specification.
How do I ensure that I’ve done it right? Requirements engineering work products are
reviewed with stakeholders to ensure what you have learned is what they really meant.
Unit II:
Understanding Requirements: Requirements Engineering, Establishing the groundwork, Eliciting
Requirements, Developing Use Cases,
Requirements, Validating Requirements.
Building the requirements model, Negotiating
Requirements Modeling (Scenarios, Information and Analysis Classes): Requirements
Analysis, Scenario-Based Modeling, UML Models that Supplement the Use Case, Data Modeling
Concepts, Class-Based Modeling.
Requirements Modeling (Flow, Behavior, Patterns and WEBAPPS): Requirements Modeling
Strategies, Flow-Oriented Modeling, Creating a Behavioral Model, Patterns for Requirements
Modeling, Requirements Modeling for WebApps.

2.1 REQUIREMENTS ENGINEERING
The broad spectrum of tasks and techniques that lead to an understanding of requirements is
called requirements engineering. From a software process perspective, requirements
engineering is a major software engineering action that begins during the communication activity
and continues into the modeling activity. It must be adapted to the needs of the process, the
project, the product, and the people doing the work.
Requirements engineering builds a bridge to design and construction. Requirements engineering
provides the appropriate mechanism for understanding what the customer wants, analyzing need,
assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously,
validating the specification, and managing the requirements as they are transformed into an
operational system. It encompasses seven distinct tasks: inception, elicitation, elaboration,
negotiation, specification, validation, and management.
a) Inception. In general, most projects begin when a business need is identified or a potential
new market or service is discovered. Stakeholders from the business community define a business
case for the idea, try to identify the breadth and depth of the market, do a rough feasibility analysis,
and identify a working description of the project’s scope.
At project inception, you establish a basic understanding of the problem, the people who want a
solution, the nature of the solution that is desired, and the effectiveness of preliminary
communication and collaboration between the other stakeholders and the software team.
b)Elicitation. Ask the customer, what the objectives for the system or product are, what is to be
accomplished, how the system or product fits into the needs of the business, and finally, how the
system or product is to be used on a day-to-day basis. A number of problems that are encountered
as elicitation occurs.
• Problems of scope. The boundary of the system is ill-defined or the customers/users specify
unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
• Problems of understanding. The customers/users are not completely sure of what is needed,
have a poor understanding of the capabilities and limitations of their computing environment, don’t
have a full understanding of the problem domain, have trouble communicating needs to thesystem
engineer, omit information that is believed to be “obvious,” specify requirements that conflict with
the needs of other customers/users, or specify requirements that are ambiguous or un testable.
• Problems of volatility. The requirements change over time. To help overcome these problems,
you must approach requirements gathering in an organized manner.
c)Elaboration. The information obtained from the customer during inception and elicitation is
expanded and refined during elaboration. This task focuses on developing

a refined requirements model that identifies various aspects of software function, behavior, and
information.
Elaboration is driven by the creation and refinement of user scenarios that describe how the end
user (and other actors) will interact with the system. Each user scenario is parsed to extract
analysis classes—business domain entities that are visible to the end user. The attributes of each
analysis class are defined, and the services that are required by each class are identified. The
relationships and collaboration between classes are identified, and a variety of supplementary
diagrams are produced.
d)Negotiation. It usual for customers, to given limited business resources. It’s also relatively
common for different customers or users to propose conflicting requirements, arguing that their
version is “essential for our special needs.”
You have to reconcile these conflicts through a process of negotiation. Customers, users, and
other stakeholders are asked to rank requirements and then discuss conflicts
in priority. Using an iterative approach that prioritizes requirements, assesses their cost and risk,
and addresses internal conflicts, requirements are eliminated, combined, and/or modified so that
each party achieves some measure of satisfaction.
e)Specification. Specification means different things to different people. A specification can be
a written document, a set of graphical models, a formal mathematical model, a collection of usage
scenarios, a prototype, or any combination of these. Some suggest that a “standard template”
should be developed and used for a specifcation, arguing that this leads to requirements that are
presented in a consistent and therefore more understandable manner. However, it is sometimes
necessary to remain flexible when a specification is to be developed. For large systems, a written
document, combining natural language descriptions and graphical models may be the best
approach.
2.2 ESTABLISHING THE GROUNDWORK
In an ideal setting, stakeholders and software engineers work together on the same team. In such
cases, requirements engineering is simply a matter of conducting meaningful conversations with
colleagues who are well-known members of the team.
We discuss the steps required to establish the groundwork for an understanding of software
requirements—to get the project started in a way that will keep it moving forward toward a
successful solution.
2.2.1 Identifying Stakeholders: Stakeholder is “anyone who benefits in a direct or indirect way
from the system which is being developed.” The usual stakeholders are: business operations
managers, product managers, marketing people, internal and external customers, end users,

consultants, product engineers, software engineers, support and maintenance engineers. Each
stakeholder has a different view of the system, achieves different benefits when the system is
successfully developed, and is open to different risks if the development effort should fail.
2.2.2 Recognizing Multiple Viewpoints: Because many different stakeholders exist, the
requirements of the system will be explored from many different points of view. Each of these
constituencies will contribute information to the requirements engineering process. Asinformation
from multiple viewpoints is collected, emerging requirements may be inconsistent or may conflict
with one another. You should categorize all stakeholder information in a way that will allow
decision makers to choose an internally consistent set of requirements for the system.
2.2.3 Working toward Collaboration: If five stakeholders are involved in a software project, you
may have five different opinions about the proper set of requirements. Customers must collaborate
among themselves and with software engineering practitioners if a successful system is to result.
The job of a requirements engineer is to identify areas of commonality and areas of conflict or
inconsistency. Collaboration does not necessarily mean that requirements are defined by
committee. In many cases, stakeholders collaborate by providing their view of requirements, but
a strong “project champion” may make the final decision about which requirements make the cut.
2.2.4 Asking the First Questions: Questions asked at the inception of the project should be
“context free. The first set of context-free questions focuses on the customer and other
stakeholders, the overall project goals and benefits. You might ask:
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
These questions help to identify all stakeholders who will have interest in the software to be built.
In addition, the questions identify the measurable benefit of a successful implementation and
possible alternatives to custom software development.
The next set of questions enables you to gain a better understanding of the problem and allows
the customer to voice his or her perceptions about a solution:
• How would you characterize “good” output that would be generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the solution will be used?
• Will special performance issues or constraints affect the way the solution is approached?
The final set of questions focuses on the effectiveness of the communication activity itself.
• Are you the right person to answer these questions? Are your answers “official”?

• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
These questions will help to “break the ice” and initiate the communication that is essential to
successful elicitation.
2.3 ELICITING REQUIREMENTS
Requirements elicitation combines elements of problem solving, elaboration, negotiation, and
specification.
2.3.1 Collaborative Requirements Gathering: Many different approaches to collaborative
requirements gathering have been proposed.
• Meetings are conducted and attended by both software engineers and other stakeholders.
• Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all important points but informal enough
to encourage the free flow of ideas.
• A “facilitator” controls the meeting.
• A “definition mechanism” (can be work sheets, flip charts etc) is used.
The goal is to identify the problem, propose elements of the solution, negotiate different
approaches, and specify a preliminary set of solution requirements in an atmosphere that is
conducive to the accomplishment of the goal.
While reviewing the product request in the days before the meeting, each attendee is asked to
make a list of objects that are part of the environment that surrounds the system, other objects that
are to be produced by the system, and objects that are used by the system to perform its functions.
The mini-specs are presented to all stakeholders for discussion. Additions, deletions, and further
elaboration are made. In some cases, the development of mini-specs will uncover new objects,
services, constraints, or performance requirements that will be added to the original lists. During
all discussions, the team may raise an issue that cannot be resolved during the meeting. An issues
list is maintained so that these ideas will be acted on later.
2.3.2 Quality Function Deployment: Quality function deployment (QFD) is a quality
management technique that translates the needs of the customer into technical requirements for
software. QFD “concentrates on maximizing customer satisfaction from the software engineering
process”. QFD identifies three types of requirements:
Normal requirements. The objectives and goals that are stated for a product or system during
meetings with the customer. If these requirements are present, the customer is satisfied.

Examples of normal requirements might be requested types of graphical displays, specificsystem
functions, and defined levels of performance.
Expected requirements. These requirements are implicit to the product or system and may be
so fundamental that the customer does not explicitly state them. Their absence will be a cause for
significant dissatisfaction. Examples of expected requirements are: ease of human/machine
interaction, overall operational correctness and reliability, and ease of software installation.
Exciting requirements. These features go beyond the customer’s expectations and prove to be
very satisfying when present. For example, software for a new mobile phone comes with standard
features, but is coupled with a set of unexpected capabilities (e.g., multitouch screen, visual voice
mail) that delight every user of the product.
2.3.3 Usage Scenarios: As requirements are gathered, an overall vision of system functions and
features begins to materialize. However, it is difficult to move into more technical software
engineering activities until you understand how these functions and features will be used by
different classes of end users. To accomplish this, developers and users can create a set of
scenarios that identify a thread of usage for the system to be constructed.
2.3.4 Elicitation Work Products: The work products produced as a consequence of
requirements elicitation will vary depending on the size of the system or product to be built. For
most systems, the work products include
• A statement of need and feasibility.
• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who participated in requirements elicitation.
• A description of the system’s technical environment.
• A list of requirements and the domain constraints that apply to each.
• A set of usage scenarios that provide insight into the use of the system or product under
different operating conditions.
• Any prototypes developed to better define requirements.
Each of these work products is reviewed by all people who have participated in requirements
elicitation.
2.4 DEVELOPING USE CASES
In essence, a use case tells a stylized story about how an end user interacts with the system under
a specific set of circumstances. The story may be narrative text, an outline of tasks or interactions,
a template-based description, or a diagrammatic representation. Regardless of its form, a use
case depicts the software or system from the end user’s point of view.
The first step in writing a use case is to define the set of “actors” that will be involved in the story.
Actors are the different people (or devices) that use the system or product within the context of

the function and behavior that is to be described. It is important to note that an actor and an end
user are not necessarily the same thing. It is possible to identify primary actors during the first
iteration and secondary actors as more is learned about the system.
Primary actors interact to achieve required system function and derive the intended benefit from
the system. They work directly and frequently with the software. Secondary actors supportthe
system so that primary actors can do their work.
Once actors have been identified, use cases can be developed. Jacobson suggests a number of
questions that should be answered by a use case:
• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
2.5 BUILDING THE REQUIREMENTS MODEL
The intent of the analysis model is to provide a description of the required informational, functional,
and behavioral domains for a computer-based system. The model changes dynamically as you
learn more about the system to be built, and other stakeholders understand

more about what they really require. For that reason, the analysis model is a snapshot of
requirements at any given time.
2.5.1 Elements of the Requirements Model: There are many different ways to look at the
requirements for a computer-based system. Different modes of representation force you to
consider requirements from different viewpoints—an approach that has a higher probability of
uncovering omissions, inconsistencies, and ambiguity.
Scenario-based elements. The system is described from the user’s point of view using a
scenario-based approach. For example, basic use cases and their corresponding use-case
diagrams evolve into more elaborate template-based use cases. Scenario-based elements of
the requirements model are often the first part of the model that is developed. Three levels of
elaboration are shown, culminating in a scenario-based representation.
Class-based elements. Each usage scenario implies a set of objects that are manipulated as
an actor interacts with the system. These objects are categorized into classes—a collection of
things that have similar attributes and common behaviors. Example shown in figure 5.4

Behavioral elements. The behavior of a computer-based system can have a profound effect on
the design that is chosen and the implementation approach that is applied. Therefore, the
requirements model must provide modeling elements that depict behavior.
The state diagram is one method for representing the behavior of a system by depicting its states
and the events that cause the system to change state. A state is any externally observable mode
of behavior. In addition, the state diagram indicates actions taken as a consequence of a particular
event.
Flow-oriented elements. Information is transformed as it flows through a computer-basedsystem.
The system accepts input in a variety of forms, applies functions to transform it, and produces
output in a variety of forms. Input may be a control signal transmitted by a transducer,a series of
numbers typed by a human operator, a packet of information transmitted on a network link, or a
voluminous data file retrieved from secondary storage. The transform(s) may comprise a single
logical comparison, a complex numerical algorithm, or a rule-inference approach of an expert
system.
2.5.2 Analysis Patterns: Anyone who has done requirements engineering on more than a few
software projects begins to notice that certain problems reoccur across all projects within a specific
application domain. These analysis patterns suggest solutions (e.g., a class, a function,

a behavior) within the application domain that can be reused when modeling many applications.
Analysis patterns are integrated into the analysis model by reference to the pattern name. They
are also stored in a repository so that requirements engineers can use search facilities to find and
apply them. Information about an analysis pattern (and other types of patterns) is presented in a
standard template.
2.6 NEGOTIATING REQUIREMENTS
In an ideal requirements engineering context, the inception, elicitation, and elaboration tasks
determine customer requirements in sufficient detail to proceed to subsequent software
engineering activities. You may have to enter into a negotiation with one or more stakeholders.
In most cases, stakeholders are asked to balance functionality, performance, and other product
or system characteristics against cost and time-to-market. The intent of this negotiation is to
develop a project plan that meets stakeholder needs while at the same time reflecting the real-
world constraints (e.g., time, people, budget) that have been placed on the software team.
The best negotiations strive for a “win-win” result. That is, stakeholders win by getting the
system or product that satisfies the majority of their needs and you win by working to realistic and
achievable budgets and deadlines.
Boehm [Boe98] defines a set of negotiation activities at the beginning of each software process
iteration. Rather than a single customer communication activity, the following activities aredefined:
1. Identification of the system or subsystem’s key stakeholders.
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win
conditions for all concerned.
2.7 VALIDATING REQUIREMENTS
As each element of the requirements model is created, it is examined for inconsistency, omissions,
and ambiguity. The requirements represented by the model are prioritized by the stakeholders and
grouped within requirements packages that will be implemented as software increments. A review
of the requirements model addresses the following questions:
• Is each requirement consistent with the overall objectives for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do some
requirements provide a level of technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature that may not be
essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source noted for each requirement?
• Do any requirements conflict with other requirements?

• Is each requirement achievable in the technical environment that will house the system or
product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information, function, and behavior of the
system to be built?
• Has the requirements model been “partitioned” in a way that exposes progressively more
detailed information about the system?
• Have requirements patterns been used to simplify the requirements model?
Have all patterns been properly validated? Are all patterns consistent with customer
requirements?
2.8 Requirements Modeling (Scenarios, Information and Analysis Classes)
What is it? The written word is a wonderful vehicle for communication, but it is not necessarily
the best way to represent the requirements for computer software. Requirements modeling
uses a combination of text and diagrammatic forms to depict requirements in a way that is
relatively easy to understand, and more important, straightforward to review for correctness,
completeness, and consistency.
Who does it? A software engineer (sometimes called an “analyst”) builds the model using
requirements elicited from the customer.
Why is it important? To validate software requirements, you need to examine them from a
number of different points of view. In this chapter you’ll consider requirements modeling from
three different perspectives: scenario-based models, data (information) models, and class-
based models. Each represents requirements in a different “dimension,” thereby increasing the
probability that errors will be found, that inconsistency will surface, and that omissions willbe
uncovered.
What are the steps? Scenario-based modeling represents the system from the user’s point of
view. Data modeling represents the information space and depicts the data objects thatthe
software will manipulate and the relationships among them. Class-based modeling defines
objects, attributes, and relationships. Once preliminary models are created, they are refined
and analyzed to assess their clarity, completeness, and consistency.
What is the work product? A wide array of text based and diagrammatic forms may be chosen
for the requirements model. Each of these representations provides a view of one or more of
the model elements.
How do I ensure that I’ve done it right? Requirements modeling work products must be
reviewed for correctness, completeness, and consistency. They must reflect the needs of all
stakeholders and establish a foundation from which design can be conducted.

2.8.1 REQUIREMENTS ANALYSIS
Requirements analysis results in the specification of software’s operational characteristics,
indicates software’s interface with other system elements, and establishes constraints that
software must meet. Requirements analysis allows you to elaborate on basic requirements
established during the inception, elicitation, and negotiation tasks that are part of requirements
engineering. The requirements modeling action results in one or more of the following types of
models:
• Scenario-based models of requirements from the point of view of various system “actors”
• Data models that depict the information domain for the problem
• Class-oriented models that represent object-oriented classes (attributes and operations) and
the manner in which classes collaborate to achieve system requirements
• Flow-oriented models that represent the functional elements of the system and how they
transform data as it moves through the system
• Behavioral models that depict how the software behaves as a consequence of external
“events”
These models provide a software designer with information that can be translated to architectural,
interface, and component-level designs. Finally, the requirements model provides the developer
and the customer with the means to assess quality once software is built.
2.8.1.1 Overall Objectives and Philosophy: Throughout requirements modeling, your primary
focus is on what, not how. The requirements model must achieve three primary objectives: (1)
to describe what the customer requires, (2) to establish a basis for the creation of a software
design, and (3) to define a set of requirements that can be validated once the software is built. The
analysis model bridges the gap between a system-level description that describes overall system
or business functionality as it is achieved by applying software, hardware, data, human, and other
system elements and a software design This relationship is illustrated in Figure 6.1

2.8.1.2 Analysis Rules of Thumb: Arlow and Neustadt suggest a number of worthwhile rules of
thumb that should be followed when creating the analysis model:
• The model should focus on requirements that are visible within the problem or business domain.
The level of abstraction should be relatively high. “Don’t get bogged down in details”that try to
explain how the system will work.
• Each element of the requirements model should add to an overall understanding of software
requirements and provide insight into the information domain, function, and behavior of the
system.
• Delay consideration of infrastructure and other nonfunctional models until design. That is, a
database may be required, but the classes necessary to implement it, the functions required to
access it, and the behavior that will be exhibited as it is used should be considered only after
problem domain analysis has been completed.
• Minimize coupling throughout the system. It is important to represent relationships between
classes and functions. However, if the level of “interconnectedness” is extremely high, effort should
be made to reduce it.
• Be certain that the requirements model provides value to all stakeholders. Each constituency
has its own use for the model. For example, business stakeholders should use the model to
validate requirements; designers should use the model as a basis for design; QA people should
use the model to help plan acceptance tests.
• Keep the model as simple as it can be. Don’t create additional diagrams when they add no new
information. Don’t use complex notational forms, when a simple list will do.
2.8.1.3 Domain Analysis: The analysis patterns often reoccur across many applications within
a specific business domain. If these patterns are defined and categorized in a manner that allows
you to recognize and apply them to solve common problems. This improves time-to- market and
reduces development costs.
Domain analysis doesn’t look at a specific application, but rather at the domain in which the
application resides. The intent is to identify common problem solving elements that are
applicable to all applications within the domain. Domain analysis may be viewed as an umbrella
activity for the software process. Figure 6.2 illustrates key inputs and outputs for the domain
analysis process. Sources of domain knowledge are surveyed in an attempt to identify objects
that can be reused across the domain.

2.8.1.4 Requirements Modeling Approaches: One view of requirements modeling, called
structured analysis, considers data and the processes that transform the data as separate entities.
Data objects are modeled in a way that defines their attributes and relationships.Processes that
manipulate data objects are modeled in a manner that shows how they transformdata as data
objects flow through the system.
A second approach to analysis modeling, called object-oriented analysis, focuses on the definition
of classes and the manner in which they collaborate with one another. UML and the Unified
Process are predominantly object oriented.
Each element of the requirements model (Figure 6.3) presents the problem from a different point
of view. Scenario-based elements depict how the user interacts with the system and the specific
sequence of activities that occur as the software is used.
Class-based elements model the objects that the system will manipulate, the operations that will
be applied to the objects to effect the manipulation, relationships between the objects, and the
collaborations that occur between the classes that are defined. Behavioral elements depict how
external events change the state of the system or the classes that reside within it. Finally, flow-
oriented elements represent the system as an information transform, depicting how data objects
are transformed as they flow through various system functions. Analysis modeling leads to the
derivation of each of these modeling elements. However, the specific content of each element may
differ from project to project.

2.8.2 SCENARIO-BASED MODELING
Requirements modeling with UML begins with the creation of scenarios in the form of use cases,
activity diagrams, and swimlane diagrams.
2.8.2.1 Creating a Preliminary Use Case: A use case describes a specific usage scenario in
straightforward language from the point of view of a defined actor. But how do you know (1) what
to write about, (2) how much to write about it, (3) how detailed to make your description, and (4)
how to organize the description?
What to write about? The first two requirements engineering tasks—inception and elicitation—
provide you with the information you’ll need to begin writing use cases. Requirements gathering
meetings, QFD, and other requirements engineering mechanisms are used to identify
stakeholders, define the scope of the problem, specify overall operational goals, establish
priorities, outline all known functional requirements, and describe the things (objects) that will be
manipulated by the system.
To begin developing a set of use cases, list the functions or activities performed by a specific actor.
You can obtain these from a list of required system functions, through conversations with
stakeholders, or by an evaluation of activity diagrams developed as part of requirements modeling.
2.8.2.2 Refining a Preliminary Use Case: A description of alternative interactions is essential for
a complete understanding of the function that is being described by a use case. Therefore, each
step in the primary scenario is evaluated by asking the following questions.
• Can the actor take some other action at this point?
• Is it possible that the actor will encounter some error condition at this point? If so, what it be?
• Is it possible that the actor will encounter some other behavior at this point. If so, what it be?
Answers to these questions result in the creation of a set of secondary scenarios that are part of
the original use case but represent alternative behavior.
Can the actor take some other action at this point? The answer is “yes.”
Is it possible that the actor will encounter some error condition at this point? Any number of error
conditions can occur as a computer-based system operates.
Is it possible that the actor will encounter some other behavior at this point? Again the answer to
the question is “yes.”
In addition to the three generic questions suggested, the following issues should also be
explored:
• Are there cases in which some “validation function” occurs during this use case?
This implies that validation function is invoked and a potential error condition might occur.
• Are there cases in which a supporting function (or actor) will fail to respond appropriately? For
example, a user action awaits a response but the function that is to respond times out.
• Can poor system performance result in unexpected or improper user actions?

2.8.2.3 Writing a Formal Use Case: The informal use cases presented are sometimes sufficient
for requirements modeling. However, when a use case involves a critical activity or describes a
complex set of steps with a significant number of exceptions, a more formal approach may be
desirable.
2.8.3 UML MODELS THAT SUPPLEMENT THE USE CASE
A broad array of UML graphical models are as follows
2.8.3.1 Developing an Activity Diagram: The UML activity diagram supplements the use case
by providing a graphical representation of the flow of interaction within a specific scenario. Similar
to the flowchart, an activity diagram uses rounded rectangles to imply a specific system function,
arrows to represent flow through the system, decision diamonds to depict a branching decision
and solid horizontal lines to indicate that parallel activities are occurring. An activity diagram for
the ACS-DCV use case is shown in Figure 6.5.
2.8.3.2 Swimlane Diagrams: The UML swimlane diagram is a useful variation of the activity
diagram and allows you to represent the flow of activities described by the use case and at the
same time indicate which actor or analysis class has responsibility for the action described by an
activity rectangle. Responsibilities are represented as parallel segments that divide the diagram
vertically, like the lanes in a swimming pool. Refer Figure 6.6.

2.8.4 DATA MODELING CONCEPTS
If software requirements include the need to create, extend, or interface with a database or if
complex data structures must be constructed and manipulated, the software team may choose
to create a data model as part of overall requirements modeling. A software engineer or analyst
defines all data objects that are processed within the system, the relationships between the data
objects, and other information that is pertinent to the relationships. The entity-relationship diagram
(ERD) addresses these issues and represents all data objects that are entered, stored,
transformed, and produced within an application.

2.8.4.1 Data Objects: A data object is a representation of composite information that must be
understood by software. Therefore, width (a single value) would not be a valid data object, but
dimensions (incorporating height, width, and depth) could be defined as an object.
A data object can be an external entity (e.g., anything that produces or consumes information), a
thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm),
a role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a
warehouse), or a structure (e.g., a file). The description of the data object incorporates the data
object and all of its attributes.
A data object encapsulates data only—there is no reference within a data object to operations
that act on the data.
2.8.4.2 Data Attributes: Data attributes define the properties of a data object and take on one of
three different characteristics. They can be used to (1) name an instance of the data object, (2)
describe the instance, or (3) make reference to another instance in another table. In addition,
one or more of the attributes must be defined as an identifier—that is, the identifier attribute
becomes a “key” when we want to find an instance of the data object. In some cases, values for
the identifier(s) are unique, although this is not a requirement.
2.8.4.3 Relationships: Data objects are connected to one another in different ways. Consider the
two data objects, person and car. These objects can be represented using the simple notation
illustrated in Figure 6.8a. A connection is established between person and car because the two
objects are related. But what are the relationships? To determine the answer, you should
understand the role of people (owners, in this case) and cars within the context of the software
to be built. You can establish a set of object/relationship pairs that define the relevant relationships.
For example,
• A person owns a car.
• A person is insured to drive a car.
The relationships owns and insured to drive define the relevant connections between person and
car. Figure 6.8b illustrates these object-relationship pairs graphically. The arrows noted in Figure

6.8b provide important information about the directionality of the relationship and often reduce
ambiguity or misinterpretations.
2.8.5 CLASS-BASED MODELING
Class-based modeling represents the objects that the system will manipulate, the operations that
will be applied to the objects to effect the manipulation, relationships between the objects, and
the collaborations that occur between the classes that are defined. The elements of a class-
based model include classes and objects, attributes, operations, class responsibility, collaborator
(CRC) models, collaboration diagrams, and packages.
2.8.5.1 Identifying Analysis Classes
Classes are determined by underlining each noun or noun phrase and entering it into a simple
table. If the class (noun) is required to implement a solution, then it is part of the solution space;
otherwise, if a class is necessary only to describe a solution, it is part of the problem space.
Analysis classes manifest themselves in one of the following ways:
• External entities that produce or consume information to be used by a computer-based
system.
• Things (e.g., reports, displays, letters, signals) that are part of the information domain for the
problem.
• Occurrences or events (e.g., a property transfer or the completion of a series of robot
movements) that occur within the context of system operation.
• Roles (e.g., manager, engineer, salesperson) played by people who interact with the system.
• Organizational units (e.g., division, group, team) that are relevant to an application.
• Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and
the overall function of the system.
• Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or
related classes of objects.
2.8.5.2 Specifying Attributes: Attributes are the set of data objects that fully define the class
within the context of the problem. Attributes describe a class that has been selected for inclusion
in the requirements model. In essence, it is the attributes that define the class—that clarify what
is meant by the class in the context of the problem space.
To develop a meaningful set of attributes for an analysis class, you should study each use case
and select those “things” that reasonably “belong” to the class.
2.8.5.3 Defining Operations: Operations define the behavior of an object. Although many
different types of operations exist, they can generally be divided into four broad categories: (1)
operations that manipulate data in some way. (2) operations that perform a computation, (3)
operations that inquire about the state of an object, and (4) operations that monitor an object for

the occurrence of a controlling event. These functions are accomplished by operating on attributes
and/or associations. Therefore, an operation must have “knowledge” of the nature of the class’
attributes and associations.
As a first iteration at deriving a set of operations for an analysis class, you can again study a
processing narrative (or use case) and select those operations that reasonably belong to the class.
To accomplish this, the grammatical parse is again studied and verbs are isolated. Some of these
verbs will be legitimate operations and can be easily connected to a specific class.
2.8.5.4 Class-Responsibility-Collaborator (CRC) Modeling: Class-responsibility-collaborator
(CRC) modeling provides a simple means for identifying and organizing the classes that are
relevant to system or product requirements.
One purpose of CRC cards is to fail early, to fail often, and to fail inexpensively. It is a lot cheaper
to tear up a bunch of cards than it would be to reorganize a large amount of source code.
Ambler describes CRC modeling in the following way:
A CRC model is really a collection of standard index cards that represent classes. The cards are
divided into three sections. Along the top of the card you write the name of the class. In the body
of the card you list the class responsibilities on the left and the collaborators on the right.
In reality, the CRC model may make use of actual or virtual index cards. The intent is to develop
an organized representation of classes. Responsibilities are the attributes and operations that
are relevant for the class. Stated simply, a responsibility is “anything the class knows or does”.
Collaborators are those classes that are required to provide a class with the information needed
to complete a responsibility.
In general, a collaboration implies either a request for information or a request for some action.

A simple CRC index card for the FloorPlan class is illustrated in Figure 6.11. The list of
responsibilities shown on the CRC card is preliminary and subject to additions or modification. The
classes Wall and Camera are noted next to the responsibility that will require their collaboration.
Classes. Basic guidelines for identifying classes and objects were presented earlier in this
chapter. The taxonomy of class types presented in Section 6.5.1 can be extended by considering
the following categories:
• Entity classes, also called model or business classes, are extracted directly from the
statement of the problem These classes typically represent things that are to be stored in a
database and persist throughout the duration of the application.
• Boundary classes are used to create the interface (e.g., interactive screen or printed reports)
that the user sees and interacts with as the software is used. Entity objects contain information

that is important to users, but they do not display themselves. Boundary classes are designed
with the responsibility of managing the way entity objects are represented to users.
• Controller classes manage a “unit of work” from start to finish. That is, controller classes can be
designed to manage (1) the creation or update of entity objects, (2) the instantiation of boundary
objects as they obtain information from entity objects, (3) complex communication between sets
of objects, (4) validation of data communicated between objects or between the user and the
application. In general, controller classes are not considered until the design activity has begun.
Responsibilities. The five guidelines for allocating responsibilities to classes:
1. System intelligence should be distributed across classes to best address the needs of
the problem. Every application encompasses a certain degree of intelligence; that is, what the
system knows and what it can do. This intelligence can be distributed acrosss classes in a
umber of different ways. “Dumb” classes can be modeled to act as servants to a few “smart”
classes.
To determine whether system intelligence is properly distributed, the responsibilities noted on
each CRC model index card should be evaluated to determine if any class has an extraordinarily
long list of responsibilities. Example is aggregation of classes.
2. Each responsibility should be stated as generally as possible. This guideline implies that
general responsibilities (both attributes and operations) should reside high in the class hierarchy
3. Information and the behavior related to it should reside within the same class. This
achieves the object-oriented principle called encapsulation. Data and the processes that
manipulate the data should be packaged as a cohesive unit.
4. Information about one thing should be localized with a single class, not distributed
across multiple classes. A single class should take on the responsibility for storing and
manipulating a specific type of information. This responsibility should not, in general, be shared

across a number of classes. If information is distributed, software becomes more difficult to
maintain and more challenging to test.
5. Responsibilities should be shared among related classes, when appropriate. There are
many cases in which a variety of related objects must all exhibit the same behavior at the same
time.
Collaborations. Classes fulfill their responsibilities in one of two ways: (1) A class can use its own
operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or (2)a class
can collaborate with other classes.
To help in the identification of collaborators, you can examine three different generic relationships
between classes (1) the is-part-of relationship, (2) the has-knowledge-of relationship, and (3) the
depends-upon relationship.
When a complete CRC model has been developed, stakeholders can review the model using
the following approach
1. All participants in the review are given a subset of the CRC model index cards. Cards that
collaborate should be separated
2. All use-case scenarios (corresponding use-case diagrams) should be organized into
categories.
3. The review leader reads the use case deliberately.
4. When the token is passed, the holder of the Sensor card is asked to describe the
responsibilities noted on the card.
5. If the responsibilities and collaborations noted on the index cards cannot accommodate the
use case, modifications are made to the cards.
This continues until the use case is finished. When all use cases have been reviewed,
requirements modeling continue.

2.8.5.5 Associations and Dependencies: In many instances, two analysis classes are related
to one another in some fashion, much like two data objects may be related to one another. In UML
these relationships are called associations.
In some cases, an association may be further defined by indicating multiplicity. Referring to
The multiplicity constraints are illustrated in Figure 6.13, where “one or more” is represented
using 1. .*, and “0 or more” by 0 . .*. In UML, the asterisk indicates an unlimited upper bound on
the range.
2.8.5.6 Analysis Packages: An important part of analysis modeling is categorization. That is,
various elements of the analysis model are categorized in a manner that packages them as a
grouping—called an analysis package—that is given a representative name.
For example, Classes such as Tree, Landscape, Road, Wall, Bridge, Building, and VisualEffect
might fall within this category. Others focus on the characters within the game, describing their
physical features, actions, and constraints.
These classes can be grouped in analysis packages as shown in Figure 6.15. The plus sign
preceding the analysis class name in each package indicates that the classes have public
visibility and are therefore accessible from other packages.

Although they are not shown in the figure, other symbols can precede an element within a
package. A minus sign indicates that an element is hidden from all other packages and a #
symbol indicates that an element is accessible only to packages contained within a given
package.

2.9 Requirements Modeling (Flow, Behavior, Patterns and WEBAPPS)
What is it? The requirements model has many different dimensions. Flow oriented models,
behavioral models, and the special requirements analysis considerations that come into
play when WebApps are developed. Each of these modeling representations supplements
the use cases, data models, and class based models.
Who does it? A software engineer (sometimes called an “analyst”) builds the model
using requirements elicited from various stakeholders.
Why is it important? Your insight into software requirements grows in direct proportion
to the number of different requirements modeling dimensions. Although you may not have
the time, the resources, or the inclination to develop every representation, recognize that
each different modeling approach provides you with a different way of looking at the
problem. As a consequence, you will be better able to assess whether you’ve properly
specified what must be accomplished.
What are the steps? Flow-oriented modeling provides an indication of how data objects
are transformed by processing functions. Behavioral modeling depicts the states of the
system and its classes and the impact of events on these states. Pattern-based modeling
makes use of existing domain knowledge to facilitate requirements analysis. WebApp
requirements models are especially adapted for the representation of content, interaction,
function, and configuration related requirements.
What is the work product? A wide array of textbased and diagrammatic forms may be
chosen for the requirements model. Each of these representations provides a view of one
or more of the model elements.
How do I ensure that I’ve done it right? Requirements modeling work products must be
reviewed for correctness, completeness, and consistency. They must reflect the needs of
all stakeholders and establish a foundation from which design can be conducted.
2.9.1 INTRODUCTION
The requirements model has many different dimensions. Flow oriented models, behavioral
models, and the special requirements analysis considerations that come into play when WebApps
are developed. Each of these modeling representations supplements the use cases, data models,
and class based models.
2.9.2 FLOW-ORIENTED MODELING
Although the data flow diagram (DFD) and related diagrams and information are not a formal part
of UML, they can be used to complement UML diagrams and provide additional insight into system
requirements and flow.

The DFD takes an input-process-output view of a system. That is, data objects flow into the
software, are transformed by processing elements, and resultant data objects flow out of the
software. Data objects are represented by labeled arrows, and transformations are represented
by circles (also called bubbles). The DFD is presented in a hierarchical fashion. That is, the first
data flow model (sometimes called a level 0 DFD or context diagram) represents the system as
a whole. Subsequent data flow diagrams refine the context diagram, providing increasing detail
with each subsequent level.
2.9.2.1 Creating a Data Flow Model: The data flow diagram enables you to develop models of
the information domain and functional domain. As the DFD is refined into greater levels of detail,
you perform an implicit functional decomposition of the system.
A few simple guidelines of a data flow diagram:
(1) the level 0 data flow diagram should depict the software/system as a single bubble;
(2) primary input and output should be carefully noted;
(3) refinement should begin by isolating candidate processes, data objects, and data stores to
be represented at the next level;
(4) all arrows and bubbles should be labeled with meaningful names;
(5) information flow continuity must be maintained from level to level,2 and
(6) one bubble at a time should be refined. There is a natural tendency to overcomplicate the data
flow diagram. This occurs when you attempt to show too much detail too early or represent
procedural aspects of the software in lieu of information flow.
2.9.2.2 Creating a Control Flow Model: For some types of applications, the data model and the
data flow diagram are all that is necessary to obtain meaningful insight into software requirements.
However, a large class of applications are “driven” by events rather than data, produce control
information rather than reports or displays, and process information with heavy concern for time
and performance. Such applications require the use of control flow modeling in addition to data
flow modeling.

An event or control item is implemented as a Boolean value (e.g., true or false, on or off, 1 or 0) or
a discrete list of conditions (e.g., empty, jammed, full). To select potential candidate events, the
following guidelines are suggested:
• List all sensors that are “read” by the software.
• List all interrupt conditions.
• List all “switches” that are actuated by an operator.
• List all data conditions.

• Recalling the noun/verb parse that was applied to the processing narrative, review all “control
items” as possible control specification inputs/outputs.
• Describe the behavior of a system by identifying its states, identify how each state is reached,
and define the transitions between states.
• Focus on possible omissions—a very common error in specifying control
2.9.2.3 The Control Specification: A control specification (CSPEC) represents the behavior of
the system in two different ways. The CSPEC contains a state diagram that is a sequential
specification of behavior. It can also contain a program activation table—a combinatorial
specification of behavior.
Figure 7.4 depicts a preliminary state diagram for the level 1 control flow model for SafeHome.
2.9.2.4 The Process Specification: The PSPEC is a “minispecification” for each transform at the
lowest refined level of a DFD. The process specification (PSPEC) is used to describe all flowmodel
processes that appear at the final level of refinement. The content of the process specification can
include narrative text, a program design language (PDL) description of the process algorithm,
mathematical equations, tables, or UML activity diagrams.

2.9.3 CREATING A BEHAVIORAL MODEL
We can represent the behavior of the system as a function of specific events and time.
The behavioral model indicates how software will respond to external events or stimuli. To
create the model, you should perform the following steps:
1. Evaluate all use cases to fully understand the sequence of interaction within the system.
2. Identify events that drive the interaction sequence and understand how these events relate to
specific objects.
3. Create a sequence for each use case.
4. Build a state diagram for the system.
5. Review the behavioral model to verify accuracy and consistency.
2.9.3.1 Identifying Events with the Use Case: The use case represents a sequence of activities
that involves actors and the system. In general, an event occurs whenever the system and an actor
exchange information. A use case is examined for points of information exchange.
The underlined portions of the use case scenario indicate events. An actor should be identified for
each event; the information that is exchanged should be noted, and any conditions orconstraints
should be listed. Once all events have been identified, they are allocated to the objects involved.
Objects can be responsible for generating events or recognizing events that have occurred
elsewhere.
2.9.3.2 State Representations: In the context of behavioral modeling, two different
characterizations of states must be considered:
(1) The state of each class as the system performs its function and
(2) The state of the system as observed from the outside as the system performs its function.

The state of a class takes on both passive and active characteristics. A passive state is simply
the current status of all of an object’s attributes. The active state of an object indicates the
current status of the object as it undergoes a continuing transformation or processing. An event
(sometimes called a trigger) must occur to force an object to make a transition from one active
state to another. Two different behavioral representations are discussed in the paragraphs that
follow.
1) The first indicates how an individual class changes state based on external events
2) The second shows the behavior of the software as a function of time.
State diagrams for analysis classes. One component of a behavioral model is
a UML state diagram9 that represents active states for each class and the events (triggers)
that cause changes between these active states. Figure 7.6 illustrates a state diagram
for the ControlPanel object in the SafeHome security function.
Each arrow shown in Figure 7.6 represents a transition from one active state of an object to
another. The labels shown for each arrow represent the event that triggers the transition.
Sequence diagrams. The second type of behavioral representation, called a sequence diagram
in UML, indicates how events cause transitions from object to object. Once events have been
identified by examining a use case, the modeler creates a sequence diagram—a representation
of how events cause flow from one object to another as a function of time. In essence, the
sequence diagram is a shorthand version of the use case. It represents key classes and the events
that cause behavior to flow from class to class. Figure 7.7 illustrates a partial sequence diagram
for the SafeHome security function.

2.10 PATTERNS FOR REQUIREMENTS MODELING
Software patterns are a mechanism for capturing domain knowledge in a way that allows it to be
reapplied when a new problem is encountered. In some cases, the domain knowledge is applied
to a new problem within the same application domain.
Once the pattern has been discovered, it is documented by describing “explicitly the general
problem to which the pattern is applicable, the prescribed solution, assumptions and constraints
of using the pattern in practice, and often some other information about the pattern, such as the
motivation and driving forces for using the pattern, discussion of the pattern’s advantages and
disadvantages, and references to some known examples of using that pattern in practical
applications”.
The pattern can be reused when performing requirements modeling for an application within a
domain. Once an appropriate pattern is selected, it is integrated into the requirements model by
reference to the pattern name.
2.10.1 Discovering Analysis Patterns: The requirements model is comprised of a wide variety
of elements: scenario-based (use cases), data-oriented (the data model), class-based, flow-
oriented, and behavioral.
Each of these elements examines the problem from a different perspective, and each provides an
opportunity to discover patterns that may occur throughout an application domain, or by analogy,
across different application domains.
The most basic element in the description of a requirements model is the use case. A semantic
analysis pattern (SAP) “is a pattern that describes a small set of coherent use cases that together
describe a basic generic application”.

Consider the following preliminary use case for software required to control and
monitor a real-view camera and proximity sensor for an automobile:
Use case: Monitor reverse motion
Description: When the vehicle is placed in reverse gear, the control software enables a
video feed from a rear-placed video camera to the dashboard display.
This use case implies a variety of functionality that would be refined and elaborated during
requirements gathering and modeling.
2.10.2 A Requirements Pattern Example: Actuator-Sensor One of the requirements of the
SafeHome security function is the ability to monitory security sensors.
Pattern Name. Actuator-Sensor
Intent. Specify various kinds of sensors and actuators in an embedded system.
Motivation. Embedded systems usually have various kinds of sensors and actuators. These
sensors and actuators are all either directly or indirectly connected to a control unit.
Constraints
• Each passive sensor must have some method to read sensor input and attributes that
represent the sensor value.
• Each active sensor must have capabilities to broadcast update messages when its value
changes.
• Each active sensor should send a life tick, a status message issued within a specified time
frame, to detect malfunctions.
Applicability. Useful in any system in which multiple sensors and actuators are present.
Structure. A UML class diagram for the Actuator-Sensor pattern is shown in Figure 7.8.

Behavior. Figure 7.9 presents a UML sequence diagram for an example of the Actuator-Sensor
pattern as it might be applied for the SafeHome function that controls the positioning (e.g., pan,
zoom) of a security camera.
Participants. Patterns description “itemizes the classes/objects that are included in the
requirements pattern” and describes the responsibilities of each class/object (Figure 7.8). An
abbreviated list follows:
• PassiveSensor abstract: Defines an interface for passive sensors.
• PassiveBooleanSensor: Defines passive Boolean sensors.
• PassiveIntegerSensor: Defines passive integer sensors.
Collaborations. This describes how objects and classes interact with one another and how
each carries out its responsibilities.
• When the ComputingComponent needs to update the value of a PassiveSensor, it queries
the sensors, requesting the value by sending the appropriate message.

Consequences
1. Sensor and actuator classes have a common interface.
2. Class attributes can only be accessed through messages, and the class decides whether or not
to accept the message. For example, if a value of an actuator is set above a maximumvalue,
then the actuator class may not accept the message, or it might use a default maximum value.
3. The complexity of the system is potentially reduced because of the uniformity of interfaces for
actuators and sensors.
2.11 REQUIREMENTS MODELING FOR WEBAPPS
The Web development process must be agile, and analysis is time consuming
2.11.1 How Much Analysis Is Enough?: The degree to which requirements modeling for
WebApps are emphasized depends on the following factors:
• Size and complexity of WebApp increment.
• Number of stakeholders
• Size of the WebApp team.
• Degree to which members of the WebApp team have worked together before
• Degree to which the organization’s success is directly dependent on the success of the
WebApp.
2.11.2 Requirements Modeling Input: An agile version of the generic software process can be
applied when WebApps are engineered. The process incorporates a communication activity that

identifies stakeholders and user categories, the business context, defined informational and
applicative goals, general WebApp requirements, and usage scenarios—information that becomes
input to requirements modeling. This information is represented in the form of natural language
descriptions, rough outlines, sketches, and other informal representations.
To summarize, the inputs to the requirements model will be the information collected during the
communication activity—anything from an informal e-mail to a detailed project brief completewith
comprehensive usage scenarios and product specifications.
2.11.3 Requirements Modeling Output: Requirements analysis provides a disciplined
mechanism for representing and evaluating WebApp content and function. While the specific
models depend largely upon the nature of the WebApp, there are five main classes of models:
• Content model—identifies the full spectrum of content to be provided by the WebApp. Content
includes text, graphics and images, video, and audio data.
• Interaction model—describes the manner in which users interact with the WebApp.
• Functional model—defines the operations that will be applied to WebApp content and describes
other processing functions that are independent of content but necessary to the end user.
• Navigation model—defines the overall navigation strategy for the WebApp.
• Configuration model—describes the environment and infrastructure in which the WebApp
resides.
2.11.4 Content Model for WebApps: The content model contains structural elements that
provide an important view of content requirements for a WebApp. These structural elements
encompass content objects and all analysis classes—user-visible entities that are created or
manipulated as a user interacts with the WebApp.
Content can be developed prior to the implementation of the WebApp, while the WebApp is being
built, or long after the WebApp is operational. In every case, it is incorporated via navigational
reference into the overall WebApp structure. A content object might be a textual description of a
product, an article describing a news event, an action photograph taken at a sporting event, a
user’s response on a discussion forum, an animated representation of acorporate logo, a short
video of a speech, or an audio overlay for a collection of presentation slides. The content objects
might be stored as separate files, embedded directly into Web pages, or obtained dynamically
from a database. In other words, a content object is any item of cohesive information that is to be
presented to an end user. Content objects can be determined directly from use cases by examining
the scenario description for direct and indirect references to content. Refer to figure 7.10 for
content modeling.

A data tree can be created for any content that is composed of multiple content objects and data
items. The data tree is developed in an effort to define hierarchical relationships among content
objects and to provide a means for reviewing content so that omissions and inconsistencies are
uncovered before design commences. In addition, the data tree serves as the basis for content
design.
2.11.5 Interaction Model for WebApps: The vast majority of WebApps enable a “conversation”
between an end user and application functionality, content, and behavior. This conversation can
be described using an interaction model that can be composed of one or more of the following
elements: (1) use cases, (2) sequence diagrams, (3) state diagrams,16 and/or (4) user interface
prototypes.
In many instances, a set of use cases is sufficient to describe the interaction at an analysis level.
However, when the sequence of interaction is complex and involves multiple analysis classes or
many tasks, it is sometimes worthwhile to depict it using a more rigorous diagrammatic form.
Because WebApp construction tools are plentiful, relatively inexpensive, and functionally powerful,
it is best to create the interface prototype using such tools.
2.11.6 Functional Model for WebApps: Many WebApps deliver a broad array of computational
and manipulative functions that can be associated directly with content and that are often a major
goal of user-WebApp interaction. For this reason, functional requirements must be analyzed, and
when necessary, modeled.
The functional model addresses two processing elements of the WebApp, each representing a
different level of procedural abstraction:
(1) user-observable functionality that is delivered by the WebApp to end users, and

(2) the operations contained within analysis classes that implement behaviors associated with
the class.
User-observable functionality encompasses any processing functions that are initiated directly
by the user. These functions may actually be implemented using operations within analysis
classes, but from the point of view of the end user, the function is the visible outcome.
At a lower level of procedural abstraction, the requirements model describes the processing to be
performed by analysis class operations. These operations manipulate class attributes and are
involved as classes collaborate with one another to accomplish some required behavior.
Regardless of the level of procedural abstraction, the UML activity diagram can be used to
represent processing details.
2.11.7 Configuration Models for WebApps: In some cases, the configuration model is nothing
more than a list of server-side and client-side attributes. However, for more complex WebApps,
a variety of configuration complexities (e.g., distributing load among multiple servers, caching
architectures, remote databases, multiple servers serving various objects on the same Web
page) may have an impact on analysis and design.
The UML deployment diagram can be used in situations in which complex configuration
architectures must be considered.
2.11.8 Navigation Modeling: Navigation modeling considers how each user category will
navigate from one WebApp element to another. The following questions should be considered:

• Should certain elements be easier to reach (require fewer navigation steps) than others? What
is the priority for presentation?
• Should certain elements be emphasized to force users to navigate in their direction?
• How should navigation errors be handled?
• Should navigation to related groups of elements be given priority over navigation to a specific
element?
• Should navigation be accomplished via links, via search-based access, or by some other
means?
• Should certain elements be presented to users based on the context of previous navigation
actions?
• Should a navigation log be maintained for users?
• Should a full navigation map or menu be available at every point in a user’s interaction?
• Should navigation design be driven by the most commonly expected user behaviors or by the
perceived importance of the defined WebApp elements?
• Can a user “store” his previous navigation through the WebApp to expedite future usage?
• For which user category should optimal navigation be designed?
• How should links external to the WebApp be handled? Overlaying the existing browser
window? As a new browser window? As a separate frame?

3.0 DESIGN CONCEPTS
UNIT – 3
What is it? Design is what almost every engineer wants to do. It is the place where
creativity rules—where stakeholder requirements, business needs, and technical
considerations all come together in the formulation of a product or system. Design creates
a representation or model of the software, but unlike the requirements model, the design
model provides detail about software architecture, data structures, interfaces, and
components that are necessary to implement the system.
Who does it? Software engineers conduct each of the design tasks. Why is it important?
Design allows you to model the system or product that is to be built. This model can be
assessed for quality and improved before code is generated, tests are conducted, and end
users become involved in large numbers. Design is the place where software quality is
established.
What are the steps? Design depicts the software in a number of different ways. First, the
architecture of the system or product must be represented. Then, the interfaces that
connect the software to end users, to other systems and devices, and to its own constituent
components are modeled. Finally, the software components that are used to construct the
system are designed. Each of these views represents a different design action, but all must
conform to a set of basic design concepts that guide software design work.
What is the work product? A design model that encompasses architectural, interface,
component level, and deployment representations is the primary work product that is
produced during software design.
How do I ensure that I’ve done it right? The design model is assessed by the software
team in an effort to determine whether it contains errors, inconsistencies, or omissions;
whether better alternatives exist; and whether the model can be implemented within the
constraints, schedule, and cost that have been established.
Unit III:
Design Concepts: Design with Context of Software Engineering, The Design Process, Design
Concepts, The Design Model.
Architectural Design: Software Architecture, Architecture Genres, Architecture Styles,
Architectural Design, Assessing Alternative Architectural Designs, Architectural Mapping Using
Data Flow.
Component-Level Design: Component, Designing Class-Based Components, Conducting
Component-level Design, Component Level Design for WebApps, Designing Traditional
Components, Component-Based Development.

3.1 DESIGN WITHIN THE CONTEXT OF SOFTWARE ENGINEERING
Software design sits at the technical kernel of software engineering and is applied regardless of
the software process model that is used. Software design is the last software engineering action
within the modeling activity and sets the stage for construction (code generation and testing).
Each of the elements of the requirements model provides information that is necessary to create
the four design models required for a complete specification of design. The flow of information
during software design is illustrated in Figure 8.1. The requirements model, manifested by
scenario-based, class-based, flow-oriented, and behavioral elements, feed the design task.
The data/class design transforms class models into design class realizations and the requisite
data structures required to implement the software. The objects and relationships defined in the
CRC diagram and the detailed data content depicted by class attributes and other notation provide
the basis for the data design action. Part of class design may occur in conjunction with the design
of software architecture.
The architectural design defines the relationship between major structural elements of the
software, the architectural styles and design patterns that can be used to achieve the

requirements defined for the system, and the constraints that affect the way in which architecture
can be implemented.
The interface design describes how the software communicates with systems that interoperate
with it, and with humans who use it. An interface implies a flow of information (e.g., data and/or
control) and a specific type of behavior. Therefore, usage scenarios and behavioral models
provide much of the information required for interface design.
The component-level design transforms structural elements of the software architecture into a
procedural description of software components. Information obtained from the class-based
models, flow models, and behavioral models serve as the basis for component design.
During design you make decisions that will ultimately affect the success of software construction
and, as important, the ease with which software can be maintained.
Design is the place where quality is fostered in software engineering. Design provides you with
representations of software that can be assessed for quality. Design is the only way that you can
accurately translate stakeholder’s requirements into a finished software product or system.
Software design serves as the foundation for all the software engineering and software support
activities that follow. Without design, you risk building an unstable system—one that will fail
when small changes are made; one that may be difficult to test; one whose quality cannot be
assessed until late in the software process, when time is short and many dollars have already
been spent.
3.2 THE DESIGN PROCESS
Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software. That is, the design is represented at a high level of
abstraction—a level that can be directly traced to the specific system objective and more
detailed data, functional, and behavioral requirements. As design iterations occur, subsequent
refinement leads to design representations at much lower levels of abstraction. These can still
be traced to requirements, but the connection is more subtle.
3.2.1 Software Quality Guidelines and Attributes: Throughout the design process, the quality
of the evolving design is assessed with a series of technical reviews. The three characteristics that
serve as a guide for the evaluation of a good design:
• The design must implement all of the explicit requirements contained in the requirements model,
and it must accommodate all of the implicit requirements desired by stakeholders.
• The design must be a readable, understandable guide for those who generate code and for those
who test and subsequently support the software.

• The design should provide a complete picture of the software, addressing the data, functional,
and behavioral domains from an implementation perspective.
Quality Guidelines. In order to evaluate the quality of a design representation, the software team
must establish technical criteria for good design. Guide lines are as follows
1. A design should exhibit an architecture that (1) has been created using recognizable
architectural styles or patterns, (2) is composed of components that exhibit good design
characteristics (these are discussed later in this chapter), and (3) can be implemented in an
evolutionary fashion, thereby facilitating implementation and testing.
2. A design should be modular; that is, the software should be logically partitioned into elements
or subsystems.
3. A design should contain distinct representations of data, architecture, interfaces, and
components.
4. A design should lead to data structures that are appropriate for the classes to be implemented
and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
8. A design should be represented using a notation that effectively communicates its meaning.
Quality Attributes. Hewlett-Packard developed a set of software quality attributes that has been
given the acronym FURPS—functionality, usability, reliability, performance, and supportability. The
FURPS quality attributes represent a target for all software design:
• Functionality is assessed by evaluating the feature set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system.
• Usability is assessed by considering human factors, overall aesthetics, consistency, and
documentation.
• Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output
results, the mean-time-to-failure (MTTF), the ability to recover from failure, and thepredictability of
the program.
• Performance is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
• Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability—these three attributes represent a more common term, maintainability—and in
addition, testability, compatibility, configurability, the ease with which a system can be installed,
and the ease with which problems can be localized.
3.2.2 The Evolution of Software Design: The evolution of software design is a continuing
process. Early design work concentrated on criteria for the development of modular programs

and methods for refining software structures in a topdown manner. Procedural aspects of design
definition evolved into a philosophy called structured programming. Later work proposed methods
for the translation of data flow or data structure into a design definition. Newer design approaches
proposed an object-oriented approach to design derivation. More recent emphasisin software
design has been on software architecture and the design patterns that can be usedto implement
software architectures and lower levels of design abstractions. Growing emphasis on aspect-
oriented methods, model-driven development, and test-driven development emphasize
techniques for achieving more effective modularity and architectural structure in the designs that
are created.
A number of design methods, growing out of the work just noted, are being applied throughout the
industry. These methods have a number of common characteristics: (1) a mechanism for the
translation of the requirements model into a design representation, (2) a notation for representing
functional components and their interfaces, (3) heuristics for refinement and partitioning, and (4)
guidelines for quality assessment.
3.3 DESIGN CONCEPTS
Design concepts has evolved over the history of software engineering. Each concept provides the
software designer with a foundation from which more sophisticated design methods can be
applied. A brief overview of important software design concepts that span both traditional and
object-oriented software development is given below.
3.3.1 Abstraction: When you consider a modular solution to any problem, many levels of
abstraction can be posed. At the highest level of abstraction, a solution is stated in broad terms
using the language of the problem environment. At lower levels of abstraction, a more detailed
description of the solution is provided. Finally, at the lowest level of abstraction, the solution is
stated in a manner that can be directly implemented.
A procedural abstraction refers to a sequence of instructions that have a specific and limited
function. The name of a procedural abstraction implies these functions, but specific details are
suppressed. A data abstraction is a named collection of data that describes a data object.
3.3.2 Architecture: Software architecture alludes to “the overall structure of the software and
the ways in which that structure provides conceptual integrity for a system”.
In its simplest form, architecture is the structure or organization of program components (modules),
the manner in which these components interact, and the structure of data that are used by the
components.
One goal of software design is to derive an architectural rendering of a system. A set of
architectural patterns enables a software engineer to solve common design problems.

Shaw and Garlan describe a set of properties as part of an architectural design:
Structural properties. This aspect of the architectural design representation defines the
components of a system (e.g., modules, objects, filters) and the manner in which those
components are packaged and interact with one another. For example, objects are packaged to
encapsulate both data and the processing that manipulates the data and interact via the invocation
of methods.
Extra-functional properties. The architectural design description should address how the design
architecture achieves requirements for performance, capacity, reliability, security, adaptability,
and other system characteristics.
Families of related systems. The architectural design should draw upon repeatable patterns that
are commonly encountered in the design of families of similar systems. In essence, the design
should have the ability to reuse architectural building blocks.
3.3.3 Patterns: A pattern is a named nugget of insight which conveys the essence of a proven
solution to a recurring problem within a certain context amidst competing concerns. Stated
A design pattern describes a design structure that solves a particular design problem within a
specific context and amid “forces” that may have an impact on the manner in which the pattern is
applied and used.
The intent of each design pattern is to provide a description that enables a designer to determine
(1) whether the pattern is applicable to the current work
(2) whether the pattern can be reused (hence, saving design time)
(3) whether the pattern can serve as a guide for developing a similar, but functionally or
structurally different pattern.
3.3.4 Separation of Concerns: Separation of concerns is a design concept that suggests that
any complex problem can be more easily handled if it is subdivided into pieces that can each be
solved and/or optimized independently.
For two problems, p1 and p2, if the perceived complexity of p1 is greater than the perceived
complexity of p2, it follows that the effort required to solve p1 is greater than the effort required
to solve p2. As a general case, this result is intuitively obvious. It does take more time to solve a
difficult problem. It also follows that the perceived complexity of two problems when they are
combined is often greater than the sum of the perceived complexity when each is taken separately.
This leads to a divide-and-conquer strategy—it’s easier to solve a complex problem when you break
it into manageable pieces. This has important implications with regard to software modularity.
3.3.5 Modularity: Modularity is the most common manifestation of separation of concerns.
Software is divided into separately named and addressable components, sometimes called
modules, that are integrated to satisfy problem requirements. It has been stated that “modularity
is the single attribute of software that allows a program to be intellectually manageable”. The

number of control paths, span of reference, number of variables, and overall complexity would
make understanding close to impossible. In almost all instances, you should break the design into
many modules, hoping to make understanding easier and, as a consequence, reduce the cost
required to build the software.
if you subdivide software indefinitely the effort required to develop it will become negligibly small!
Unfortunately, other forces come into play, causing this conclusion to be (sadly) invalid. Referring
to Figure 8.2, the effort (cost) to develop an individual software module does decrease as the total
number of modules increases.
Given the same set of requirements, more modules means smaller individual size. However, as
the number of modules grows, the effort (cost) associated with integrating the modules also grows.
These characteristics lead to a total cost or effort curve shown in the figure. There is a number, M,
of modules that would result in minimum development cost, but we do not have the necessary
sophistication to predict M with assurance.
The curves shown in Figure 8.2 do provide useful qualitative guidance when modularity is
considered. You should modularize, but care should be taken to stay in the vicinity of M.
Undermodularity or overmodularity should be avoided.
You modularize a design (and the resulting program) so that development can be more easily
planned; software increments can be defined and delivered; changes can be more easily
accommodated; testing and debugging can be conducted more efficiently, and long-term
maintenance can be conducted without serious side effects.
3.3.6 Information Hiding: The principle of information hiding suggests that modules be
“characterized by design decisions that (each) hides from all others.” In other words, modules
should be specified and designed so that information (algorithms and data) contained within a
module is inaccessible to other modules that have no need for such information. Hiding implies
that effective modularity can be achieved by defining a set of independent modules that

communicate with one another only that information necessary to achieve software function.
Abstraction helps to define the procedural (or informational) entities that make up the software.
Hiding defines and enforces access constraints to both procedural detail within a module and any
local data structure used by the module. The use of information hiding as a design criterion for
modular systems provides the greatest benefits when modifications are required during testing
and later during software maintenance. Because most data and procedural detail are hidden from
other parts of the software, inadvertent errors introduced during modification are less likely to
propagate to other locations within the software.
3.3.7 Functional Independence: The concept of functional independence is a direct outgrowth
of separation of concerns, modularity, and the concepts of abstraction and information hiding.
Functional independence is achieved by developing modules with “singleminded” function and an
“aversion” to excessive interaction with other modules. Stated another way, you should design
software so that each module addresses a specific subset of requirements and has a simple
interface when viewed from other parts of the program structure. Independent modules are easier
to maintain (and test) because secondary effects caused by design or code modification are
limited, error propagation is reduced, and reusable modules are possible. To summarize,
functional independence is a key to good design, and design is the key to software quality.
Independence is assessed using two qualitative criteria: cohesion and coupling.
Cohesion is an indication of the relative functional strength of a module. Coupling is an indication
of the relative interdependence among modules.
A cohesive module performs a single task, requiring little interaction with other components in
other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing.
Although you should always strive for high cohesion (i.e., single-mindedness), it is often necessary
and advisable to have a software component perform multiple functions.
Coupling is an indication of interconnection among modules in a software structure. Coupling
depends on the interface complexity between modules, the point at which entry or reference is
made to a module, and what data pass across the interface. In software design, you should strive
for the lowest possible coupling. Simple connectivity among modules results in software that is
easier to understand and less prone to a “ripple effect”, caused when errors occur at one location
and propagate throughout a system.
3.3.8 Refinement: Stepwise refinement is a top-down design strategy. . A program is developed
by successively refining levels of procedural detail. A hierarchy is developed by decomposing a
macroscopic statement of function (a procedural abstraction) in a stepwise fashion until
programming language statements are reached.

Refinement is actually a process of elaboration begins with a statement of function (or description
of information) that is defined at a high level of abstraction. You then elaborate onthe original
statement, providing more and more detail as each successive refinement (elaboration) occurs.
Refinement helps you to reveal low-level details as design progresses.
3.3.9 Aspects: As requirements analysis occurs, a set of “concerns” is uncovered. These
concerns “include requirements, use cases, features, data structures, quality-of-service issues,
variants, intellectual property boundaries, collaborations, patterns and contracts”. Ideally, a
requirements model can be organized in a way that allows you to isolate each concern
(requirement) so that it can be considered independently. In practice, however, some of these
concerns span the entire system and cannot be easily compartmentalized.
As design begins, requirements are refined into a modular design representation. Consider two
requirements, A and B. Requirement A crosscuts requirement B “if a software decomposition
[refinement] has been chosen in which B cannot be satisfied without taking A into account”.
3.3.10 Refactoring: An important design activity for many agile methods is refactoring a
reorganization technique that simplifies the design (or code) of a component without changing its
function or behavior. “Refactoring is the process of changing a software system in such a way that
it does not alter the external behavior of the code [design] yet improves its internal structure.”
When software is refactored, the existing design is examined for redundancy, unused design
elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data
structures, or any other design failure that can be corrected to yield a better design. The result will
be software that is easier to integrate, easier to test, and easier to maintain.
3.3.11 Object-Oriented Design Concepts: The object-oriented (OO) paradigm is widely used
in modern software engineering. OO design concepts such as classes and objects, inheritance,
messages, and polymorphism, among others.
3.3.12 Design Classes: As the design model evolves, you will define a set of design classes that
refine the analysis classes by providing design detail that will enable the classes to be
implemented, and implement a software infrastructure that supports the business solution.
Five different types of design classes, each representing a different layer of the design
architecture, can be developed.
• User interface classes define all abstractions that are necessary for human computer interaction
(HCI). In many cases, HCI occurs within the context of a metaphor (e.g., a checkbook, an order
form, a fax machine), and the design classes for the interface may be visual representations of
the elements of the metaphor.

• Business domain classes are often refinements of the analysis classes. The classes identify
the attributes and services (methods) that are required to implement some element of the business
domain.
• Process classes implement lower-level business abstractions required to fully manage the
business domain classes.
• Persistent classes represent data stores (e.g., a database) that will persist beyond the execution
of the software.
• System classes implement software management and control functions that enable the system
to operate and communicate within its computing environment and with the outside world.
They define four characteristics of a well-formed design class:
Complete and sufficient. A design class should be the complete encapsulation of all attributes
and methods that can reasonably be expected (based on a knowledgeable interpretation of the
class name) to exist for the class.
Primitiveness. Methods associated with a design class should be focused on accomplishing one
service for the class. Once the service has been implemented with a method, the class should not
provide another way to accomplish the same thing.
High cohesion. A cohesive design class has a small, focused set of responsibilities and single-
mindedly applies attributes and methods to implement those responsibilities.
Low coupling. Within the design model, it is necessary for design classes to collaborate with one
another. However, collaboration should be kept to an acceptable minimum. If a design model is
highly coupled, the system is difficult to implement, to test, and to maintain over time. In general,
design classes within a subsystem should have only limited knowledge of other classes.This
restriction, called the Law of Demeter, suggests that a method should only send messages to
methods in neighboring classes.
3.4 THE DESIGN MODEL
The design model can be viewed in two different dimensions as illustrated in Figure 8.4. The
process dimension indicates the evolution of the design model as design tasks are executed as
part of the software process. The abstraction dimension represents the level of detail as each
element of the analysis model is transformed into a design equivalent and then refined iteratively.
Referring to Figure 8.4, the dashed line indicates the boundary between the analysis and design
models. The analysis model slowly blends into the design and a clear distinction is less obvious.
The elements of the design model use UML diagrams, that were used in the analysis model. The
difference is that these diagrams are refined and elaborated as part of design; more
implementation-specific detail is provided, and architectural structure and style, components that
reside within the architecture, and interfaces between the components and with the outside world
are all emphasized.

You should note, however, that model elements indicated along the horizontal axis are not always
developed in a sequential fashion. The deployment model is usually delayed until the design has
been fully developed.
3.4.1 Data Design Elements: Like other software engineering activities, data design (sometimes
referred to as data architecting) creates a model of data and/or information that is represented at
a high level of abstraction. This data model is then refined into progressively more implementation-
specific representations that can be processed by the computer-based system.
The structure of data has always been an important part of software design. At the program
component level, the design of data structures and the associated algorithms required to
manipulate them is essential to the creation of high-quality applications. At the application level,
the translation of a data model into a database is pivotal to achieving the business objectives ofa
system. At the business level, the collection of information stored in disparate databases and
reorganized into a “data warehouse” enables data mining or knowledge discovery that can have
an impact on the success of the business itself.
3.4.2 Architectural Design Elements: The architectural design for software is the equivalent to
the floor plan of a house. The floor plan gives us an overall view of the house. Architectural

design elements give us an overall view of the software. The architectural model is derived from
three sources:
(1) information about the application domain for the software to be built;
(2) specific requirements model elements such as data flow diagrams or analysis classes, their
relationships and collaborations for the problem at hand; and
(3) the availability of architectural styles and patterns.
The architectural design element is usually depicted as a set of interconnected subsystems,
Each subsystem may have it’s own architecture
3.4.3 Interface Design Elements: The interface design for software is analogous to a set of
detailed drawings for the doors, windows, and external utilities of a house. The interface design
elements for software depict information flows into and out of the system and how it is
communicated among the components defined as part of the architecture.
There are three important elements of interface design:
(1) the user interface (UI);
(2) external interfaces to other systems, devices, networks, or other producers or consumers of
information; and
(3) internal interfaces between various design components.
These interface design elements allow the software to communicate externally and enable internal
communication and collaboration among the components that populate the software architecture.
UI design (increasingly called usability design) is a major software engineering action. Usability
design incorporates aesthetic elements (e.g., layout, color, graphics, interaction mechanisms),
ergonomic elements (e.g., information layout and placement, metaphors, UI navigation), and
technical elements (e.g., UI patterns, reusable components).
The design of external interfaces requires definitive information about the entity to which
information is sent or received. The design of internal interfaces is closely aligned with component-
level design.
3.4.4 Component-Level Design Elements: The component-level design for software is the
equivalent to a set of detailed drawings (and specifications) for each room in a house. The
component-level design for software fully describes the internal detail of each software
component. To accomplish this, the component-level design defines data structures for all local
data objects and algorithmic detail for all processing that occurs within a component and an
interface that allows access to all component operations (behaviors). Within the context of object-
oriented software engineering, a component is represented in UML diagrammatic form as shown
in Figure 8.6.
A UML activity diagram can be used to represent processing logic. Detailed procedural flow for a
component can be represented using either pseudocode or some other diagrammatic form (e.g.,

flowchart or box diagram). Algorithmic structure follows the rules established for structured
programming (i.e., a set of constrained procedural constructs). Data structures, selected based on
the nature of the data objects to be processed, are usually modeled using pseudocode or the
programming language to be used for implementation.
3.4.5 Deployment-Level Design Elements: Deployment-level design elements indicate how
software functionality and subsystems will be allocated within the physical computingenvironment
that will support the software.
During design, a UML deployment diagram is developed and then refined as shown in Figure
8.7. The diagram shown is in descriptor form. This means that the deployment diagram shows the
computing environment but does not explicitly indicate configuration details.

3.5 SOFTWARE ARCHITECTURE
(Architecture  Architecture Style  Architecture Pattern  Design)
What is it? Architectural design represents the structure of data and program components
that are required to build a computer-based system. It considers the architectural style that
the system will take, the structure and properties of the components that constitute the
system, and the interrelationships that occur among all architectural components of asystem.
Who does it? Although a software engineer can design both data and architecture, the job
is often allocated to specialists when large, complex systems are to be built. A database or
data warehouse designer creates the data architecture for a system. The “system architect”
selects an appropriate architectural style from the requirements derived during software
requirements analysis.
Why is it important? It provides you with the big picture and ensures that you’ve got it
right.
What are the steps? Architectural design begins with data design and then proceeds to
the derivation of one or more representations of the architectural structure of the system.
Alternative architectural styles or patterns are analyzed to derive the structure that is best
suited to customer requirements and quality attributes. Once an alternative has been
selected, the architecture is elaborated using an architectural design method.
What is the work product? An architecture model encompassing data architecture and
program structure is created during architectural design. In addition, component properties
and relationships (interactions) are described.
How do I ensure that I’ve done it right? At each stage, software design work products are
reviewed for clarity, correctness, completeness, and consistency with requirements andwith
one another.
3.5.1 What Is Architecture? :Software architecture must model the structure of a system
and the manner in which data and procedural components collaborate with one another.
The software architecture of a program or computing system is the structure or structures of the
system, which comprise software components, the externally visible properties of those
components, and the relationships among them.
The architecture is not the operational software. Rather, it is a representation that enables you to
(1) analyze the effectiveness of the design in meeting its stated requirements
(2) architectural alternatives at a stage when making design changes is still relatively easy
(3) reduce the risks associated with the construction of the software.
This definition emphasizes the role of “software components” in any architectural representation.
In the context of architectural design, a software component can be something as simple as a

program module or an object-oriented class, but it can also be extended to include databases and
“middleware” that enable the configuration of a network of clients and servers. The properties of
components are those characteristics that are necessary for an understanding of how the
components interact with other components. At the architectural level, internal properties (e.g.,
details of an algorithm) are not specified. The relationships between components can be as simple
as a procedure call from one module to another or as complex asa database access protocol.
There is a distinct difference between the terms architecture and design. A design is an instance
of an architecture similar to an object being an instance of a class. For example, consider the
client-server architecture. I can design a network-centric software system in many different ways
from this architecture using either the Java platform (Java EE) or Microsoft platform (.NET
framework). So, there is one architecture, but many designs can be created based on that
architecture. Architectural design focuses on the representation of the structure of software
components, their properties, and interactions.
3.5.1.2 Why Is Architecture Important?: Three key reasons that software architecture is
important:
• Representations of software architecture are an enabler for communication between all parties
(stakeholders) interested in the development of a computer-based system.
• The architecture highlights early design decisions that will have a profound impact on all software
engineering work that follows and, as important, on the ultimate success of the system as an
operational entity.
• Architecture “constitutes a relatively small, intellectually graspable model of how the system is
structured and how its components work together”.
3.5.1.3 Architectural Descriptions: Different stakeholders will see an architecture from different
viewpoints that are driven by different sets of concerns. This implies that an architectural
description is actually a set of work products that reflect different views of the system.
Tyree and Akerman note this when they write: “Developers want clear, decisive guidance on how
to proceed with design. Customers want a clear understanding on the environmental changes that
must occur and assurances that the architecture will meet their business needs. Other architects
want a clear, salient understanding of the architecture’s key aspects.” Each of these “wants” is
reflected in a different view represented using a different viewpoint.
The IEEE standard defines an architectural description (AD) as “a collection of products to
document an architecture.” The description itself is represented using multiple views, where each
view is “a representation of a whole system from the perspective of a related set of [stakeholder]
concerns.”

3.5.1.4 Architectural Decisions: Each view developed as part of an architectural description
addresses a specific stakeholder concern. To develop each view the system architect considers
a variety of alternatives and ultimately decides on the specific architectural features that best meet
the concern. Therefore, architectural decisions themselves can be considered to be one view of
the architecture.
3.5.2 ARCHITECTURAL GENRES
Although the underlying principles of architectural design apply to all types of architecture, the
architectural genre will often dictate the specific architectural approach to the structure that must
be built. In the context of architectural design, genre implies a specific category within the overall
software domain. Within each category, you encounter a number of subcategories. For example,
within the genre of buildings, you would encounter the following general styles: houses, condos,
apartment buildings, office buildings, industrial building, warehouses, and so on.
Grady Booch suggests the following architectural genres for software-based systems:
• Artificial intelligence—Systems that simulate or augment human cognition, locomotion, or
other organic processes.
• Commercial and nonprofit—Systems that are fundamental to the operation of a business
enterprise.
• Communications—Systems that provide the infrastructure for transferring and managing
data, for connecting users of that data, or for presenting data at the edge of an infrastructure.
• Content authoring—Systems that are used to create or manipulate textual or multimedia
artifacts.
• Devices—Systems that interact with the physical world to provide some point service for an
individual.
• Entertainment and sports—Systems that manage public events or that provide a large group
entertainment experience.
• Financial—Systems that provide the infrastructure for transferring and managing money and
other securities.
• Games—Systems that provide an entertainment experience for individuals or groups.
• Government—Systems that support the conduct and operations of a local, state, federal,
global, or other political entity.
• Industrial—Systems that simulate or control physical processes.
• Legal—Systems that support the legal industry.
• Medical—Systems that diagnose or heal or that contribute to medical research.
• Military—Systems for consultation, communications, command, control, and intelligence (C4I)
as well as offensive and defensive weapons.
• Operating systems—Systems that sit just above hardware to provide basic software services.
• Platforms—Systems that sit just above operating systems to provide advanced services.

• Scientific—Systems that are used for scientific research and applications.
• Tools—Systems that are used to develop other systems.
• Transportation—Systems that control water, ground, air, or space vehicles.
• Utilities—Systems that interact with other software to provide some point service.
SAI (Software Architecture for Immersipresence) is a new software architecture model for
designing, analyzing and implementing applications performing distributed, asynchronous parallel
processing of generic data streams. The goal of SAI is to provide a universal framework for the
distributed implementation of algorithms and their easy integration into complex systems.
3.6 ARCHITECTURAL STYLES
Architectural style describes a system category that encompasses
(1) a set of components (e.g., a database, computational modules) that perform a function
required by a system;
(2) a set of connectors that enable “communication, coordination and cooperation” among
components;
(3) constraints that define how components can be integrated to form the system; and
(4) semantic models that enable a designer to understand the overall properties of a system by
analyzing the known properties of its constituent parts.
An architectural style is a transformation that is imposed on the design of an entire system. The
intent is to establish a structure for all components of the system.
An architectural pattern, like an architectural style, imposes a transformation on the design of an
architecture. However, a pattern differs from a style in a number of fundamental ways:
(1) the scope of a pattern is less broad, focusing on one aspect of the architecture rather than
the architecture in its entirety;
(2) a pattern imposes a rule on the architecture, describing how the software will handle some
aspect of its functionality at the infrastructure level (e.g., concurrency)
(3) architectural patterns tend to address specific behavioral issues within the context of the
architecture (e.g., how real-time applications handle synchronization or interrupts).
Patterns can be used in conjunction with an architectural style to shape the overall structure of a
system.
3.6.1 A Brief Taxonomy of Architectural Styles: Although millions of computer-based systems
have been created over the past 60 years, the vast majority can be categorized into one of a
relatively small number of architectural styles:
Data-centered architectures. A data store (e.g., a file or database) resides at the center of this
architecture and is accessed frequently by other components that update, add, delete, or
otherwise modify data within the store. Figure 9.1 illustrates a typical data-centered style. Client

software accesses a central repository. In some cases the data repository is passive. That is, client
software accesses the data independent of any changes to the data or the actions of other client
software. Data-centered architectures promote integrability. That is, existing components can be
changed and new client components added to the architecture without concern about other clients
(because the client components operate independently). In addition, data can be passed among
clients using the blackboard mechanism (i.e., the blackboard component serves to coordinate the
transfer of information between clients). Client components independently execute processes.
Data-flow architectures. This architecture is applied when input data are to be transformed
through a series of computational or manipulative components into output data. A pipe-and-filter
pattern (Figure 9.2) has a set of components, called filters, connected by pipes that transmit data
from one component to the next. Each filter works independently of those components upstream
and downstream, is designed to expect data input of a certain form, and produces data output (to
the next filter) of a specified form. However, the filter does not require knowledge of the workings
of its neighboring filters.

Call and return architectures. This architectural style enables you to achieve a program structure
that is relatively easy to modify and scale. A number of substyles exist within this category:
• Main program/subprogram architectures. This classic program structure decomposes function
into a control hierarchy where a “main” program invokes a number of program components that
in turn may invoke still other components. Figure 9.3 illustrates an architecture of this type.
• Remote procedure call architectures. The components of a main program/subprogram
architecture are distributed across multiple computers on a network.

Object-oriented architectures. The components of a system encapsulate data and the
operations that must be applied to manipulate the data. Communication and coordination between
components are accomplished via message passing.
Layered architectures. The basic structure of a layered architecture is illustrated in Figure 9.4.
A number of different layers are defined, each accomplishing operations that progressively
become closer to the machine instruction set. At the outer layer, components service user interface
operations. At the inner layer, components perform operating system interfacing. Intermediate
layers provide utility services and application software functions. These architectural styles are
only a small subset of those available. Once requirements engineering uncovers the
characteristics and constraints of the system to be built, the architectural style and/or combination
of patterns that best fits those characteristics and constraints can be chosen.For example, a
layered style (appropriate for most systems) can be combined with a data- centered architecture
in many database applications.
3.6.2 Architectural Patterns: Architectural patterns address an application-specific problem
within a specific context and under a set of limitations and constraints. The pattern proposes an
architectural solution that can serve as the basis for architectural design.
For example, the overall architectural style for an application might be call-and-return or object-
oriented. But within that style, you will encounter a set of common problems that might best be
addressed with specific architectural patterns.
3.6.3 Organization and Refinement: Because the design process often leaves you with a
number of architectural alternatives, it is important to establish a set of design criteria that can be
used to assess an architectural design that is derived. The following questions provide insight
into an architectural style:

Control. How is control managed within the architecture? Does a distinct control hierarchy exist,
and if so, what is the role of components within this control hierarchy? How do components transfer
control within the system? How is control shared among components? What is the control topology
(i.e., the geometric form that the control takes)? Is control synchronized or do components operate
asynchronously?
Data. How are data communicated between components? Is the flow of data continuous, or are
data objects passed to the system sporadically? What is the mode of data transfer (i.e., are data
passed from one component to another or are data available globally to be shared among system
components)? Do data components (e.g., a blackboard or repository) exist, and if so, what is their
role? How do functional components interact with data components? Are data components
passive or active (i.e., does the data component actively interact with other components in the
system)? How do data and control interact within the system?
These questions provide the designer with an early assessment of design quality and lay the
foundation for more detailed analysis of the architecture.
3.7 ARCHITECTURAL DESIGN
The design should define the external entities (other systems, devices, people) that the software
interacts with and the nature of the interaction. This information can generally be acquired from
the requirements model and all other information gathered during requirements engineering. Once
context is modeled and all external software interfaces have been described, you can identify a
set of architectural archetypes. An archetype is an abstraction (similar to a class) that represents
one element of system behavior. The set of archetypes provides a collection of abstractions that
must be modeled architecturally if the system is to be constructed, but the archetypes themselves
do not provide enough implementation detail.
Therefore, the designer specifies the structure of the system by defining and refining software
components that implement each archetype. This process continues iteratively until a complete
architectural structure has been derived.
3.7.1 Representing the System in Context: Architectural context represents how the software
interacts with entities external to its boundaries. At the architectural design level, a software
architect uses an architectural context diagram (ACD) to model the manner in which software
interacts with entities external to its boundaries. The generic structure of the architectural context
diagram is illustrated in Figure 9.5. Referring to the figure, systems that interoperate with the target
system are represented as
• Superordinate systems—those systems that use the target system as part of some higher-level
processing scheme.
• Subordinate systems—those systems that are used by the target system and provide data or
processing that are necessary to complete target system functionality.

• Peer-level systems—those systems that interact on a peer-to-peer basis (i.e.,information is either
produced or consumed by the peers and the target system.
• Actors—entities (people, devices) that interact with the target system by producing or
consuming information that is necessary for requisite processing. Each of these external entities
communicates with the target system through an interface (the small shaded rectangles).
3.7.2 Defining Archetypes: Archetypes are the abstract building blocks of an architectural
design. An archetype is a class or pattern that represents a core abstraction that is critical to the
design of an architecture for the target system. In general, a relatively small set of archetypes is
required to design even relatively complex systems. The target system architecture is composed
of these archetypes, which represent stable elements of the architecture but may be instantiated
many different ways based on the behavior of the system.
The following are the archetypes for safeHome: Node, Detector, Indicator., Controller.

3.7.3 Refining the Architecture into Components: As the software architecture is refined into
components, the structure of the system begins to emerge. The architecture must accommodate
many infrastructure components that enable application components but have no business
connection to the application domain. For example, memory management components,
communication components, database components, and task management components are often
integrated into the software architecture.
As an example for SafeHome home security, the set of top-level components that address the
following functionality:
• External communication management—coordinates communication of the security function
with external entities such as other Internet-based systems and external alarm notification.
• Control panel processing—manages all control panel functionality.
• Detector management—coordinates access to all detectors attached to the system.
• Alarm processing—verifies and acts on all alarm conditions.
Each of these top-level components would have to be elaborated iteratively and then positioned
within the overall SafeHome architecture.
3.7.4 Describing Instantiations of the System: The architectural design that has been modeled
to this point is still relatively high level. The context of the system has been represented,
archetypes that indicate the important abstractions within the problem domain havebeen defined,
the overall structure of the system is apparent, and the major software components have been
identified. However, further refinement is still necessary.

3.8 ASSESSING ALTERNATIVE ARCHITECTURAL DESIGNS
Design results in a number of architectural alternatives that are each assessed to determine which
is the most appropriate for the problem to be solved. Two different approaches for the assessment
of alternative architectural designs. The first method uses an iterative method to assess design
trade-offs. The second approach applies a pseudo-quantitative technique for assessing design
quality.
3.8.1 An Architecture Trade-Off Analysis Method: The Software Engineering Institute (SEI)
has developed an architecture trade-off analysis method (ATAM) that establishes an iterative
evaluation process for software architectures. The design analysis activities that follow are
performed iteratively:
1. Collect scenarios. A set of use cases is developed to represent the system from the user’s
point of view.
2. Elicit requirements, constraints, and environment description. This information is determined as
part of requirements engineering and is used to be certain that all stakeholder concerns have been
addressed.
3. Describe the architectural styles/patterns that have been chosen to address the scenarios and
requirements. The architectural style(s) should be described using one of the following
architectural views:
• Module view for analysis of work assignments with components and the degree to which
information hiding has been achieved.
• Process view for analysis of system performance.
• Data flow view for analysis of the degree to which the architecture meets functional
requirements.
4. Evaluate quality attributes by considering each attribute in isolation. The number of quality
attributes chosen for analysis is a function of the time available for review and the degree to which
quality attributes are relevant to the system at hand. Quality attributes for architectural design
assessment include reliability, performance, security, maintainability, flexibility, testability,
portability, reusability, and interoperability.
5. Identify the sensitivity of quality attributes to various architectural attributes for a specific
architectural style. This can be accomplished by making small changes in the architecture and
determining how sensitive a quality attribute, say performance, is to the change. Any attributes
that are significantly affected by variation in the architecture are termed sensitivity points.
6. Critique candidate architectures using the sensitivity analysis conducted in step 5.
The SEI describes this approach in the following manner.
Once the architectural sensitivity points have been determined, finding trade-off points is simply
the identification of architectural elements to which multiple attributes are sensitive.

These six steps represent the first ATAM iteration. Based on the results of steps 5 and 6, some
architecture alternatives may be eliminated, one or more of the remaining architectures may be
modified and represented in more detail, and then the ATAM steps are reapplied.
3.8.2 Architectural Complexity: A useful technique for assessing the overall complexity of a
proposed architecture is to consider dependencies between components within the architecture.
These dependencies are driven by information/control flow within the system.
The three types of dependencies:
Sharing dependencies represent dependence relationships among consumers who use the same
resource or producers who produce for the same consumers. For example, for twocomponents u
and v, if u and v refer to the same global data, then there exists a shared dependence relationship
between u and v.
Flow dependencies represent dependence relationships between producers and consumers
of resources. For example, for two components u and v, if u must complete before control flows
into v (prerequisite), or if u communicates with v by parameters, then there exists a flow
dependence relationship between u and v.
Constrained dependencies represent constraints on the relative flow of control among a set of
activities. For example, for two components u and v, u and v cannot execute at the same time
(mutual exclusion), then there exists a constrained dependence relationship between u and v.
3.8.3 Architectural Description Languages: Architectural description language (ADL) provides
a semantics and syntax for describing a software architecture. Hofmann and his colleagues
suggest that an ADL should provide the designer with the ability to decompose architectural
components, compose individual components into larger architectural blocks, and represent
interfaces (connection mechanisms) between components. Once descriptive, language based
techniques for architectural design have been established, it is more likely that effective
assessment methods for architectures will be established as the design evolves.
3.9 ARCHITECTURAL MAPPING USING DATA FLOW
There is no practical mapping for some architectural styles, and the designer must approach the
translation of requirements to design for these styles in using the techniques.
To illustrate one approach to architectural mapping, consider the call and return architecture—an
extremely common structure for many types of systems. The call and return architecture can reside
within other more sophisticated architectures. For example, the architecture of one ormore
components of a client-server architecture might be call and return. A mapping technique, called
structured design, is often characterized as a data flow-oriented design method because itprovides
a convenient transition from a data flow diagram to software architecture. The transitionfrom
information flow (represented as a DFD) to program structure is accomplished as part of a six step
process: (1) the type of information flow is established, (2) flow boundaries are

indicated, (3) the DFD is mapped into the program structure, (4) control hierarchy is defined, (5)
the resultant structure is refined using design measures and heuristics, and (6) the architectural
description is refined and elaborated.
3.9.1 Transform Mapping: Transform mapping is a set of design steps that allows a DFD with
transform flow characteristics to be mapped into a specific architectural style.
Step 1. Review the fundamental system model. The fundamental system model or context
diagram depicts the security function as a single transformation, representing the external
producers and consumers of data that flow into and out of the function. Figure 9.10 depicts a level
0 context model, and Figure 9.11 shows refined data flow for the security function.

Step 2. Review and refine data flow diagrams for the software. Information obtained from the
requirements model is refined to produce greater detail. For example, the level 2 DFD for monitor
sensors (Figure 9.12) is examined, and a level 3 data flow diagram is derived as shown in Figure
9.13. The data flow diagram exhibits relatively high cohesion.

Step 3. Determine whether the DFD has transform or transaction flow characteristics.
Evaluating the DFD (Figure 9.13), we see data entering the software along one incoming path and
exiting along three outgoing paths. Therefore, an overall transform characteristic will be assumed
for information flow.
Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries.
Incoming data flows along a path in which information is converted from external to internal form;
outgoing flow converts internalized data to external form. Incoming and outgoing flow boundaries
are open to interpretation. That is, different designers may select slightly different points in the
flow as boundary locations. Flow boundaries for the example are illustratedas shaded curves
running vertically through the flow in Figure 9.13. The transforms (bubbles) that constitute the
transform center lie within the two shaded boundaries that run from top to bottom in the figure. An
argument can be made to readjust a boundary. The emphasis in this design step should be on
selecting reasonable boundaries, rather than lengthy iteration on placement of divisions.
Step 5. Perform “first-level factoring.” The program architecture derived using this mapping
results in a top-down distribution of control. Factoring leads to a program structure in which top-
level components perform decision making and low level components perform most input,
computation, and output work. Middle-level components perform some control and do moderate
amounts of work.
Step 6. Perform “second-level factoring.” Second-level factoring is accomplished by mapping
individual transforms (bubbles) of a DFD into appropriate modules within the architecture.

Step 7. Refine the first-iteration architecture using design heuristics for improved software
quality. A first-iteration architecture can always be refined by applying concepts of functional
independence. Components are exploded or imploded to produce sensible factoring, separation
of concerns, good cohesion, minimal coupling, and most important, a structure that can be
implemented without difficulty, tested without confusion, and maintained without grief.
3.9.2 Refining the Architectural Design: Refinement of software architecture during early
stages of design is to be encouraged. Alternative architectural styles may be derived, refined,
and evaluated for the “best” approach. This approach to optimization is one of the true benefits
derived by developing a representation of software architecture.
It is important to note that structural simplicity often reflects both elegance and efficiency. Design
refinement should strive for the smallest number of components that is consistent with effective
modularity and the least complex data structure that adequately serves information requirements.
3.10 Component-Level Design
What is it? Component-level design defines the data structures, algorithms, interface
characteristics, and communication mechanisms allocated to each software component.
Who does it? A software engineer performs component-level design.
Why is it important? You have to be able to determine whether the software will work before
you build it. The component-level design represents the software in a way that allows you to
review the details of the design for correctness and consistency with other design
representations (i.e., the data, architectural, and interface designs). It provides a means for
assessing whether data structures, interfaces, and algorithms will work.
What are the steps? Design representations of data, architecture, and interfaces form the
foundation for component-level design. The class definition or processing narrative for each
component is translated into a detailed design that makes use of diagrammatic or text- based
forms that specify internal data structures, local interface detail, and processing logic. Design
notation encompasses UML diagrams and supplementary forms. Procedural design is
specified using a set of structured programming constructs. It is often possible to acquire
existing reusable software components rather than building new ones.
What is the work product? The design for each component, represented in graphical,
tabular, or text-based notation, is the primary work product produced during component- level
design.
How do I ensure that I’ve done it right? A design review is conducted. The design is
examined to determine whether data structures, interfaces, processing sequences, andlogical
conditions are correct and will produce the appropriate data or control transformation allocated
to the component during earlier design steps.

3.10 WHAT IS A COMPONENT?: A component is a modular building block for computer
software. More formally, component is “a modular, deployable, and replaceable part of a system
that encapsulates implementation and exposes a set of interfaces.”
Components populate the software architecture and, as a consequence, play a role in achieving
the objectives and requirements of the system to be built. Because components reside within the
software architecture, they must communicate and collaborate with other components and with
entities (e.g., other systems, devices, people) that exist outside the boundaries of the software.
3.10.1 An Object-Oriented View: In the context of object-oriented software engineering, a
component contains a set of collaborating classes. Each class within a component has been
fully elaborated to include all attributes and operations that are relevant to its implementation. As
part of the design elaboration, all interfaces that enable the classes to communicate and
collaborate with other design classes must also be defined.

3.10.2 The Traditional View: In the context of traditional software engineering, a component is
a functional element of a program that incorporates processing logic, the internal data structures
that are required to implement the processing logic, and an interface that enables the component
to be invoked and data to be passed to it. A traditional component, also called a module, resides
within the software architecture and serves one of three important roles:
(1) a control component that coordinates the invocation of all other problem domain components,
(2) a problem domain component that implements a complete or partial function that is required
by the customer, or
(3) an infrastructure component that is responsible for functions that support the processing
required in the problem domain.
Like object-oriented components, traditional software components are derived from the analysis
model. To achieve effective modularity, design concepts like functional independence are applied
as components are elaborated.
During component-level design, each module in Figure 10.2 is elaborated. The module interface
is defined explicitly. That is, each data or control object that flows across the interface is
represented. The data structures that are used internal to the module are defined. The algorithm
that allows the module to accomplish its intended function is designed using the stepwise

refinement approach. The behavior of the module is sometimes represented using a state diagram.
Figure 10.3 represents the component-level design using a modified UML notation.
3.10.3 A Process-Related View: The object-oriented and traditional views of component-level
design assume that the component is being designed from scratch. That is, you have to create a
new component based on specifications derived from the requirements model.
Over the past two decades, the software engineering community has emphasized the need to
build systems that make use of existing software components or design patterns. In essence, a
catalog of proven design or code-level components is made available to you as design work
proceeds. As the software architecture is developed, you choose components or design patterns
from the catalog and use them to populate the architecture.
Because these components have been created with reusability in mind, a complete description of
their interface, the function(s) they perform, and the communication and collaboration they require
are all available.

3.11 DESIGNING CLASS-BASED COMPONENTS
When an object-oriented software engineering approach is chosen, component-level design
focuses on the elaboration of problem domain specific classes and the definition and refinement
of infrastructure classes contained in the requirements model. The detailed description of the
attributes, operations, and interfaces used by these classes is the design detail required as a
precursor to the construction activity.
3.11.1 Basic Design Principles: Four basic design principles are applicable to component-level
design and have been widely adopted when object-oriented software engineering is applied.
The Open-Closed Principle (OCP). “A module [component] should be open for extension but
closed for modification”. This statement seems to be a contradiction, but it represents one of the
most important characteristics of a good component-level design. Stated simply, you should
specify the component in a way that allows it to be extended without the need to make internal
(code or logic-level) modifications to the component itself. To accomplish this, you create
abstractions that serve as a buffer between the functionality that is likely to be extended and the
design class itself.
The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for their base
classes”. This design principle, originally proposed by Barbara Liskov, suggests that a component
that uses a base class should continue to function properly if a class derived fromthe base
class is passed to the component instead. LSP demands that any class derived from a base class
must honor any implied contract between the base class and the components that use it.
Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on
concretions”. As we have seen in the discussion of the OCP, abstractions are the place where a
design can be extended without great complication. The more a component depends on other

concrete components (rather than on abstractions such as an interface), the more difficult it will
be to extend.
The Interface Segregation Principle (ISP). “Many client-specific interfaces are better than one
general purpose interface”. There are many instances in which multiple client components use the
operations provided by a server class. ISP suggests that you should create a specialized interface
to serve each major category of clients. Only those operations that are relevant to a particular
category of clients should be specified in the interface for that client. If multiple clients require the
same operations, it should be specified in each of the specialized interfaces.
Martin suggests additional packaging principles that are applicable to component-level design:
The Release Reuse Equivalency Principle (REP). “The granule of reuse is the granule of
release”. When classes or components are designed for reuse, there is an implicit contract that
is established between the developer of the reusable entity and the people who will use it.
Rather than addressing each class individually, it is often advisable to group reusable classes
into packages that can be managed and controlled as newer versions evolve.
The Common Closure Principle (CCP). “Classes that change together belong together.” Classes
should be packaged cohesively. That is, when classes are packaged as part of a design, they
should address the same functional or behavioral area. When some characteristic of that area
must change, it is likely that only those classes within the package will require modification. This
leads to more effective change control and release management.
The Common Reuse Principle (CRP). “Classes that aren’t reused together should not be
grouped together” If classes are not grouped cohesively, it is possible that a class with no
relationship to other classes within a package is changed. This will precipitate unnecessary
integration and testing. For this reason, only classes that are reused together should be included
within a package.
3.11.2 Component-Level Design Guidelines: Ambler suggests the following guidelines for
components, their interfaces, and the dependencies and inheritance characteristics
Components. Naming conventions should be established for components that are specified as
part of the architectural model and then refined and elaborated as part of the component-level
model. Architectural component names should be drawn from the problem domain and should
have meaning to all stakeholders who view the architectural model.
Interfaces. Interfaces provide important information about communication and collaboration.
However, unfettered representation of interfaces tends to complicate component diagrams.
Ambler recommends that (1) lollipop representation of an interface should be used in lieu of the
more formal UML box and dashed arrow approach, when diagrams grow complex; (2) for
consistency, interfaces should flow from the left-hand side of the component box; (3) only those
interfaces that are relevant to the component under consideration should be shown, even if other
interfaces are available.

Dependencies and Inheritance. For improved readability, it is a good to model dependencies
from left to right and inheritance from bottom (derived classes) to top (base classes). In addition,
component interdependencies should be represented via interfaces, rather than by representation
of a component-to-component dependency.
3.11.3 Cohesion: Cohesion is the “single-mindedness” of a component. Within the context of
component-level design for object-oriented systems, cohesion implies that a component or class
encapsulates only attributes and operations that are closely related to one another and to the class
or component itself. Lethbridge and Laganiére define a number of different types ofcohesion.
Functional. Exhibited primarily by operations, this level of cohesion occurs when a component
performs a targeted computation and then returns a result.
Layer. Exhibited by packages, components, and classes, this type of cohesion occurs when a
higher layer accesses the services of a lower layer, but lower layers do not access higher layers.
It might be possible to define a set of layered packages as shown in Figure 10.5. The shaded
packages contain infrastructure components.
Communicational. All operations that access the same data are defined within one class. In
general, such classes focus solely on the data in question, accessing and storing it. Classes and
components that exhibit functional, layer, and communicational cohesion are relatively easy to
implement, test, and maintain.
3.11.4 Coupling: Communication and collaboration are essential elements of any object-
oriented system. Coupling is a qualitative measure of the degree to which classes are connected
toone another. As classes (and components) become more interdependent, coupling increases.
An important objective in component-level design is to keep coupling as low as is possible.
Lethbridge and Laganiére define the following coupling categories:
Content coupling. Occurs when one component “surreptitiously modifies data that is internal to
another component”. This violates information hiding—a basic design concept.

Common coupling. Occurs when a number of components all make use of a global variable.
Although this is sometimes necessary (e.g., for establishing default values that are applicable
throughout an application), common coupling can lead to uncontrolled error propagation and
unforeseen side effects when changes are made.
Control coupling. Occurs when operation A() invokes operation B() and passes a control flag to
B. The control flag then “directs” logical flow within B. The problem with this form of coupling is
that an unrelated change in B can result in the necessity to change the meaning of the control flag
that A passes. If this is overlooked, an error will result.
Stamp coupling. Occurs when ClassB is declared as a type for an argument of an operation of
ClassA. Because ClassB is now a part of the definition of ClassA, modifying the system becomes
more complex.
Data coupling. Occurs when operations pass long strings of data arguments. The “bandwidth” of
communication between classes and components grows and the complexity of the interface
increases. Testing and maintenance are more difficult.
Routine call coupling. Occurs when one operation invokes another. This level of coupling is
common and is often quite necessary. However, it does increase the connectedness of asystem.
Type use coupling. Occurs when component A uses a data type defined in component B (e.g.,
this occurs whenever “a class declares an instance variable or a local variable as having another
class for its type”. If the type definition changes, every component that uses the definition must
also change.
Inclusion or import coupling. Occurs when component A imports or includes a package or the
content of component B.
External coupling. Occurs when a component communicates or collaborates with infrastructure
components (e.g., operating system functions, database capability, telecommunication functions).
Although this type of coupling is necessary, it should be limited to a small number of components
or classes within a system.
Software must communicate internally and externally. Therefore, coupling is a fact of life.
However, the designer should work to reduce coupling whenever possible and understand the
ramifications of high coupling when it cannot be avoided.
3.11.5 CONDUCTING COMPONENT-LEVEL DESIGN: The following steps represent a typical
task set for component-level design, when it is applied for an object-oriented system.
Step 1. Identify all design classes that correspond to the problem domain. Using the
requirements and architectural model, each analysis class and architectural component is
elaborated.
Step 2. Identify all design classes that correspond to the infrastructure domain. These
classes are not described in the requirements model and are often missing from the architecture
model, but they must be described at this point. As we have noted earlier, classes and components
in this category include GUI components, operating system components, and objectand data
management components.

Step 3. Elaborate all design classes that are not acquired as reusable components.
Elaboration requires that all interfaces, attributes, and operations necessary to implement the
class be described in detail. Design heuristics (e.g., component cohesion and coupling) must be
considered as this task is conducted.
Step 3a. Specify message details when classes or components collaborate. The
requirements model makes use of a collaboration diagram to show how analysis classes
collaborate with one another. As component-level design proceeds, it is sometimes useful to show
the details of these collaborations by specifying the structure of messages that are passed
between objects within a system. Although this design activity is optional, it can be used as a
precursor to the specification of interfaces that show how components within the system
communicate and collaborate. Figure 10.6 illustrates a simple collaboration diagram for the
printing system.
Step 3b. Identify appropriate interfaces for each component. Within the context of component-
level design, a UML interface is “a group of externally visible (i.e., public) operations. The interface
contains no internal structure, it has no attributes, no associations. Interface is the equivalent of
an abstract class that provides a controlled connection between design classes.
Step 3c. Elaborate attributes and define data types and data structures required to
implement them. In general, data structures and types used to define attributes are defined within
the context of the programming language that is to be used for implementation. UML defines an
attribute’s data type using the following syntax:
name : type-expression _ initial-value {property string}
where name is the attribute name, type expression is the data type, initial value is the value that
the attribute takes when an object is created, and property-string defines a property or
characteristic of the attribute.

Step 3d. Describe processing flow within each operation in detail. This may be accomplished
using a programming language-based pseudocode or with a UML activity diagram. Each software
component is elaborated through a number of iterations that apply the stepwise refinement
concept.
The first iteration defines each operation as part of the design class. In every case, the operation
should be characterized in a way that ensures high cohesion; that is, the operation should perform
a single targeted function or subfunction. The next iteration does little more than expand the
operation name. Figure 10.8 depicts a UML activity diagram for computePaperCost().
Step 4. Describe persistent data sources (databases and files) and identify the classes
required to manage them. Databases and files normally transcend the design description of an

individual component. In most cases, these persistent data stores are initially specified as part of
architectural design. However, as design elaboration proceeds, it is often useful to provide
additional detail about the structure and organization of these persistent data sources.
Step 5. Develop and elaborate behavioral representations for a class or component. UML
state diagrams were used as part of the requirements model to represent the externally observable
behavior of the system and the more localized behavior of individual analysis classes. During
component-level design, it is sometimes necessary to model the behavior of a design class. The
dynamic behavior of an object is affected by events that are external to it and the current state of
the object as illustrated in Figure 10.9.
Step 6. Elaborate deployment diagrams to provide additional implementation detail.
Deployment diagrams are used as part of architectural design and are represented in descriptor
form. In this form, major system functions are represented within the context of the computing
environment that will house them.
Step 7. Refactor every component-level design representation and always consider
alternatives. The design is an iterative process. The first component-level model you create will
not be as complete, consistent, or accurate as the nth iteration you apply to the model. It is essential
to refactor as design work is conducted. Develop alternatives and consider each carefully, using
the design principles and concepts.

3.12 COMPONENT-LEVEL DESIGN FOR WEBAPPS
WebApp component is (1) a well-defined cohesive function that manipulates content or provides
computational or data processing for an end user or (2) a cohesive package of content and
functionality that provides the end user with some required capability. Therefore, component- level
design for WebApps often incorporates elements of content design and functional design.
3.12.1 Content Design at the Component Level: Content design at the component level focuses
on content objects and the manner in which they may be packaged for presentation to a WebApp
end user.
The formality of content design at the component level should be tuned to the characteristics of
the WebApp to be built. In many cases, content objects need not be organized as components
and can be manipulated individually. However, as the size and complexity grows, it may be
necessary to organize content in a way that allows easier reference and design manipulation. In
addition, if content is highly dynamic, it becomes important to establish a clear structural model
that incorporates content components.
3.12.2 Functional Design at the Component Level: Modern Web applications deliver
increasingly sophisticated processing functions that (1) perform localized processing to generate
content and navigation capability in a dynamic fashion, (2) provide computation or data processing
capability that is appropriate for the WebApp’s business domain, (3) provide sophisticated
database query and access, or (4) establish data interfaces with external corporatesystems.
To achieve these (and many other) capabilities, you will design and construct WebApp functional
components that are similar in form to software components for conventional software. During
architectural design, WebApp content and functionality are combined to create a functional
architecture. A functional architecture is a representation of the functional domain of the WebApp
and describes the key functional components in the WebApp and how these components interact
with each other.
3.13 DESIGNING TRADITIONAL COMPONENTS
The foundations of component-level design for traditional software components were formed in
the early 1960s and were solidified with the work of Edsger Dijkstra and his colleagues. The
constructs emphasized “maintenance of functional domain.” That is, each construct had a
predictable logical structure and was entered at the top and exited at the bottom, enabling a reader
to follow procedural flow more easily.
The constructs are sequence, condition, and repetition. Sequence implements processing steps
that are essential in the specification of any algorithm. Condition provides the facility for selected

processing based on some logical occurrence, and repetition allows for looping. These three
constructs are fundamental to structured programming—an important component-level design
technique. The structured constructs were proposed to limit the procedural design of software to
a small number of predictable logical structures.
Complexity metrics indicate that the use of the structured constructs reduces program complexity
and thereby enhances readability, testability, and maintainability.
The structured constructs are logical chunks that allow a reader to recognize procedural elements
of a module, rather than reading the design or code line by line. Understanding is enhanced when
readily recognizable logical patterns are encountered.
3.13.1 Graphical Design Notation: ”A picture is worth a thousand words”. There is no question
that graphical tools, such as the UML activity diagram or the flowchart, provide useful pictorial
patterns that readily depict procedural detail.
The activity diagram allows you to represent sequence, condition, and repetition—all elements of
structured programming—and is a descendent of an earlier pictorial design representation called
a flowchart. A box is used to indicate a processing step. A diamond represents a logical condition,
and arrows show the flow of control. Figure 10.10 illustrates three structured constructs.
The sequence is represented as two processing boxes connected by a line (arrow) of control.
Condition, also called if-then-else, is depicted as a decision diamond that, if true, causes then- part
processing to occur, and if false, invokes else-part processing. Repetition is represented using
two slightly different forms. The do while tests a condition and executes a loop task

repetitively as long as the condition holds true. A repeat until executes the loop task first and then
tests a condition and repeats the task until the condition fails. The selection (or select-case)
construct shown in the figure is actually an extension of the if-then-else. A parameter is tested by
successive decisions until a true condition occurs and a case part processing path is executed.
3.13.2 Tabular Design Notation: Decision tables provide a notation that translates actions and
conditions (described in a processing narrative or a use case) into a tabular form. The table is
difficult to misinterpret and may even be used as a machine-readable input to a table-driven
algorithm. Decision table organization is illustrated in Figure 10.11. Referring to the figure, the
table is divided into four sections. The upper left-hand quadrant contains a list of all conditions.
The lower left-hand quadrant contains a list of all actions that are possible based on combinations
of conditions. The right-hand quadrants form a matrix that indicates condition combinations and
the corresponding actions that will occur for a specific combination. Therefore,each column of the
matrix may be interpreted as a processing rule. The following steps are applied to develop a
decision table:
1. List all actions that can be associated with a specific procedure (or component).
2. List all conditions (or decisions made) during execution of the procedure.
3. Associate specific sets of conditions with specific actions, eliminating impossible combinations
of conditions; alternatively, develop every possible permutation of conditions.
4. Define rules by indicating what actions occur for a set of conditions.
3.13.3 Program Design Language: Program design language (PDL), also called structured
English or pseudocode, incorporates the logical structure of a programming language with the
free-form expressive ability of a natural language (e.g., English). Narrative text (e.g., English) is
embedded within a programming language-like syntax. Automated tools can be used to enhance
the application of PDL.

A basic PDL syntax should include constructs for component definition, interface description, data
declaration, block structuring, condition constructs, repetition constructs, and input-output (I/O)
constructs. It should be noted that PDL can be extended to include keywords for multitasking
and/or concurrent processing, interrupt handling, interprocess synchronization, and many other
features. The application design for which PDL is to be used should dictate the final form for the
design language. The format and semantics for some of these PDL constructs are presented in
the example that follows.
3.14 COMPONENT-BASED DEVELOPMENT
Component-based software engineering (CBSE) is a process that emphasizes the design and
construction of computer-based systems using reusable software “components.”
3.14.1 Domain Engineering: The intent of domain engineering is to identify, construct, catalog,
and disseminate a set of software components that have applicability to existing and future
software in a particular application domain. The overall goal is to establish mechanisms that
enable software engineers to share these components—to reuse them—during work on new and
existing systems. Domain engineering includes three major activities—analysis, construction, and
dissemination.
The overall approach to domain analysis is often characterized within the context of object-
oriented software engineering. The steps in the process are defined as:
1. Define the domain to be investigated.
2. Categorize the items extracted from the domain.
3. Collect a representative sample of applications in the domain.

4. Analyze each application in the sample and define analysis classes.
5. Develop a requirements model for the classes.
It is important to note that domain analysis is applicable to any software engineering paradigm
and may be applied for conventional as well as object-oriented development.
3.14.2 Component Qualification, Adaptation, and Composition: Domain engineering
provides the library of reusable components that are required for component-based software
engineering. Some of these reusable components are developed in-house, others can be
extracted from existing applications, and still others may be acquired from third parties.
Unfortunately, the existence of reusable components does not guarantee that these components
can be integrated easily or effectively into the architecture chosen for a new application. It is for
this reason that a sequence of component-based development actions is applied when a
component is proposed for use.
Component Qualification. Component qualification ensures that a candidate component will
perform the function required, will properly “fit” into the architectural style specified for the system,
and will exhibit the quality characteristics (e.g., performance, reliability, usability) thatare
required for the application.
An interface description provides useful information about the operation and use of a software
component, but it does not provide all of the information required to determine if a proposed
component can, in fact, be reused effectively in a new application. Among the many factors
considered during component qualification are:
• Application programming interface (API).
• Development and integration tools required by the component.
• Run-time requirements, including resource usage (e.g., memory or storage), timing or speed,
and network protocol.
• Service requirements, including operating system interfaces and support from other
components.
• Security features, including access controls and authentication protocol.
• Embedded design assumptions, including the use of specific numerical or nonnumerical
algorithms.
• Exception handling
Component Adaptation. In an ideal setting, domain engineering creates a library of components
that can be easily integrated into an application architecture. The implication of “easy integration”
is that (1) consistent methods of resource management have been implemented for all
components in the library, (2) common activities such as data management exist for all
components, and (3) interfaces within the architecture and with the external environment have
been implemented in a consistent manner.

Conflicts may occur in one or more of the areas in selection of components. To avoid these
conflicts, an adaptation technique called component wrapping is sometimes used. When a
software team has full access to the internal design and code for a component white-box wrapping
is applied. Like its counterpart in software testing white-box wrapping examines the internal
processing details of the component and makes code-level modifications to remove any conflict.
Gray-box wrapping is applied when the component library provides a component extension
language or API that enables conflicts to be removed or masked. Black-box wrapping requires the
introduction of pre- and postprocessing at the component interface to remove or mask conflicts.
Component Composition. The component composition task assembles qualified, adapted, and
engineered components to populate the architecture established for an application. To accomplish
this, an infrastructure and coordination must be established to bind the components into an
operational system.
OMG/CORBA. The Object Management Group has published a common object request broker
architecture (OMG/CORBA). An object request broker (ORB) provides a variety of services that
enable reusable components (objects) to communicate with other components, regardless of their
location within a system.
Microsoft COM and .NET. Microsoft has developed a component object model (COM) that
provides a specification for using components produced by various vendors within a single
application running under the Windows operating system. From the point of view of the application,
“the focus is not on how implemented, only on the fact that the object has an interface that it
registers with the system, and that it uses the component system to communicate with other COM
objects”. The Microsoft .NET framework encompasses COM and provides a reusable class library
that covers a wide array of application domains.
Sun JavaBeans Components. The JavaBeans component system is a portable, platform-
independent CBSE infrastructure developed using the Java programming language. The
JavaBeans component system encompasses a set of tools, called the Bean Development Kit
(BDK), that allows developers to (1) analyze how existing Beans (components) work, (2)
customize their behavior and appearance, (3) establish mechanisms for coordination and
communication, (4) develop custom Beans for use in a specific application, and (5) test and
evaluate Bean behavior.
3.14.3 Analysis and Design for Reuse: Design concepts such as abstraction, hiding, functional
independence, refinement, and structured programming, along with object-oriented methods,
testing, software quality assurance (SQA), and correctness verification methods all contribute to
the creation of software components that are reusable.
The requirements model is analyzed to determine those elements that point to existing reusable
components. Elements of the requirements model are compared to WebRef descriptions of
reusable components in a process that is sometimes referred to as “specification matching”. If
specification matching points to an existing component that fits the needs of the current

application, you can extract the component from a reuse library (repository) and use it in the design
of a new system. If components cannot be found (i.e., there is no match), a newcomponent is
created i.e design for reuse (DFR) should be considered.
Standard data. The application domain should be investigated and standard global data
structures (e.g., file structures or a complete database) should be identified. All design
components can then be characterized to make use of these standard data structures.
Standard interface protocols. Three levels of interface protocol should be established: the
nature of intramodular interfaces, the design of external technical (nonhuman) interfaces, and the
human-computer interface.
Program templates. An architectural style is chosen and can serve as a template for the
architectural design of a new software. Once standard data, interfaces, and program templates
have been established, you have a framework in which to create the design. New components that
conform to this framework have a higher probability for subsequent reuse.
3.14.4 Classifying and Retrieving Components: Consider a large component repository. Tens
of thousands of reusable software components reside in it.
A reusable software component can be described in many ways, but an ideal description
encompasses the 3C model—concept, content, and context. The concept of a software component
is “a description of what the component does”. The interface to the component is fully described
and the semantics—represented within the context of pre- and post conditions—is identified. The
content of a component describes how the concept is realized. The context places a reusable
software component within its domain of applicability.
A reuse environment exhibits the following characteristics:
• A component database capable of storing software components and the classification
information necessary to retrieve them.
• A library management system that provides access to the database.
• A software component retrieval system (e.g., an object request broker) that enables a client
application to retrieve components and services from the library server.
• CBSE tools that support the integration of reused components into a new design or
implementation.
Each of these functions interact with or is embodied within the confines of a reuse library.
The reuse library is one element of a larger software repository and provides facilities for the
storage of software components and a wide variety of reusable work products (e.g., specifications,
designs, patterns, frameworks, code fragments, test cases, user guides).
If an initial query results in a voluminous list of candidate components, the query is refined to
narrow the list. Concept and content information are then extracted (after candidate components
are found) to assist you in selecting the proper component.

UNIT – 4
4.0 USER INTERFACE DESIGN
What is it? User interface design creates an effective communication medium between a
human and a computer. Following a set of interface design principles, design identifies
interface objects and actions and then creates a screen layout that forms the basis for a
user interface prototype.
Who does it? A software engineer designs the user interface by applying an iterative
process that draws on predefined design principles.
Why is it important? If software is difficult to use, if it forces you into mistakes, or if it
frustrates your efforts to accomplish your goals, you won’t like it, regardless of the
computational power it exhibits, the content it delivers, or the functionality it offers. The
interface has to be right because it molds a user’s perception of the software.
What are the steps? User interface design begins with the identification of user, task, and
environmental requirements. Once user tasks have been identified, user scenarios are
created and analyzed to define a set of interface objects and actions. These form the basis
for the creation of screen layout that depicts graphical design and placement of icons,
definition of descriptive screen text, specification and titling for windows, and specification
of major and minor menu items. Tools are used to prototype and ultimately implement the
design model, and the result is evaluated for quality.
What is the work product? User scenarios are created and screen layouts are generated.
An interface prototype is developed and modified in an iterative fashion.
How do I ensure that I’ve done it right? An interface prototype is “test driven” by the
users, and feedback from the test drive is used for the next iterative modification of the
prototype.
Unit IV:
User Interface Design: The Golden Rules, User Interface Analysis and Design, Interface Analysis,
Interface Design Steps, WebApp Interface Design, Design Evaluation.
WebApp Design: WebApp Design Quality, Design Goal, A Desigin Pyramid for WebApps,
WebApp Interface Design, Aestheic Design, Content Design, Architecture Design, Navigation
Design, Component-Level Design, Object-Oriented Hypermedia Design Method(OOHMD).

4.1 THE GOLDEN RULES
The three golden rules on interface design are
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.
These golden rules actually form the basis for a set of user interface design principles that guide
this important aspect of software design.
4.1.1 Place the User in Control: During a requirements-gathering session for a major new
information system, a key user was asked about the attributes of the window-oriented graphical
interface. User wanted to control the computer, not have the computer control her. Most interface
constraints and restrictions that are imposed by a designer are intended to simplify the mode of
interaction. The result may be an interface that is easy to build, but frustrating to use. Mandel
defines a number of design principles that allow the user to maintain control:
Define interaction modes in a way that does not force a user into unnecessary or undesired
actions. An interaction mode is the current state of the interface. For example, if spell check is
selected in a word-processor menu, the software moves to a spell-checking mode. There is no
reason to force the user to remain in spell-checking mode if the user desires to makea small text
edit along the way. The user should be able to enter and exit the mode with little or no effort.
Provide for flexible interaction. Because different users have different interaction preferences,
choices should be provided. For example, software might allow a user to interact via keyboard
commands, mouse movement, a digitizer pen, a multi touch screen, or voice recognition
commands.
Allow user interaction to be interruptible and undoable. Even when involved in a sequence
of actions, the user should be able to interrupt the sequence to do something else (without losing
the work that had been done). The user should also be able to “undo” any action.
Streamline interaction as skill levels advance and allow the interaction to be customized.
Users often find that they perform the same sequence of interactions repeatedly. It is worthwhile
to design a “macro” mechanism that enables an advanced user to customize the interface to
facilitate interaction.
Hide technical internals from the casual user. The user interface should move the user into the
virtual world of the application. The user should not be aware of the operating system, file
management functions, or other arcane computing technology. In essence, the interface should
never require that the user interact at a level that is “inside” the machine (e.g., a user should never
be required to type operating system commands from within application software).
Design for direct interaction with objects that appear on the screen. The user feels a sense
of control when able to manipulate the objects that are necessary to perform a task in a manner
similar to what would occur if the object were a physical thing. For example, an application
interface that allows a user to “stretch” an object is an implementation of direct manipulation.

4.1.2 Reduce the User’s Memory Load: The more a user has to remember, the more error-
prone the interaction with the system will be. It is for this reason that a well-designed user interface
does not tax the user’s memory.
Reduce demand on short-term memory. When users are involved in complex tasks, the
demand on short-term memory can be significant. The interface should be designed to reduce the
requirement to remember past actions, inputs, and results.
Establish meaningful defaults. The initial set of defaults should make sense for the average
user, but a user should be able to specify individual preferences.
Define shortcuts that are intuitive. When mnemonics are used to accomplish a system function
(e.g., alt-P to invoke the print function), the mnemonic should be tied to the action in a way that is
easy to remember.
The visual layout of the interface should be based on a real-world metaphor. For example,
a bill payment system should use a checkbook and check register metaphor to guide the user
through the bill paying process. This enables the user to rely on well-understood visual cues, rather
than memorizing an arcane interaction sequence.
Disclose information in a progressive fashion. The interface should be organized
hierarchically. That is, information about a task, an object, or some behavior should be presented
first at a high level of abstraction. More detail should be presented after the user indicates interest
with a mouse pick.
4.1.3 Make the Interface Consistent: The interface should present and acquire information in a
consistent fashion. This implies that (1) all visual information is organized according to design rules
that are maintained throughout all screen displays, (2) input mechanisms are constrainedto a
limited set that is used consistently throughout the application, and (3) mechanisms for navigating
from task to task are consistently defined and implemented.
Allow the user to put the current task into a meaningful context. Many interfaces implement
complex layers of interactions with dozens of screen images. It is important to provide indicators
(e.g., window titles, graphical icons, consistent color coding) that enable the user to know the
context of the work at hand. In addition, the user should be able to determine where he has come
from and what alternatives exist for a transition to a new task.
Maintain consistency across a family of applications. A set of applications (or products)
should all implement the same design rules so that consistency is maintained for all interaction.
If past interactive models have created user expectations, do not make changes unless there is
a compelling reason to do so. Once a particular interactive sequence has become a de facto
standard the user expects this in every application he encounters. A change will cause
confusion.

4.2 USER INTERFACE ANALYSIS AND DESIGN
The overall process for analyzing and designing a user interface begins with the creation of
different models of system function. Tools are used to prototype and ultimately implement the
design model, and the result is evaluated by end users for quality.
4.2.1 Interface Analysis and Design Models: Four different models come into play when a user
interface is to be analyzed and designed. To build an effective user interface, “all design should
begin with an understanding of the intended users, including profiles of their age, gender, physical
abilities, education, cultural or ethnic background, motivation, goals and personality . In addition,
users can be categorized as:
Novices. No syntactic knowledge of the system and little semantic knowledge of the application
or computer usage in general.
Knowledgeable, intermittent users. Reasonable semantic knowledge of the application but
relatively low recall of syntactic information necessary to use the interface.
Knowledgeable, frequent users. Good semantic and syntactic knowledge that often leads to the
“power-user syndrome”; that is, individuals who look for shortcuts and abbreviated modes of
interaction.
The user’s mental model (system perception) is the image of the system that end users carry in
their heads. For example, if the user of a particular word processor were asked to describe its
operation, the system perception would guide the response.
The implementation model combines the outward manifestation of the computer based system
(look and feel interface), coupled with all supporting information (books, manuals, videotapes,
help) that describes interface syntax and semantics. When the implementation model and the
user’s mental model are coincident, users generally feel comfortable with the software and use it
effectively. In essence, these models enable the interface designer to satisfy a key element of the
most important principle of user interface design: “Know the user, know the tasks.”
4.2.2 The Process: The analysis and design process for user interfaces is iterative and can be
represented using a spiral model. Referring to Figure 11.1, the four distinct framework activities:
(1) interface analysis and modeling, (2) interface design, (3) interface construction, and (4)
interface validation. The spiral shown in Figure 11.1 implies that each of these tasks will
occur more than once, with each pass around the spiral representing additional elaboration of
requirements and the resultant design.
In most cases, the construction activity involves prototyping—the only practical way to validate what
has been designed. Interface analysis focuses on the profile of the users who will interact with the
system. Skill level, business understanding, and general receptiveness to the new system are
recorded; and different user categories are defined. For each user category, requirements are
elicited. In essence, you work to understand the system perception for each class of users.

Once general requirements have been defined, a more detailed task analysis is conducted. Those
tasks that the user performs to accomplish the goals of the system are identified, described, and
elaborated.
Finally, analysis of the user environment focuses on the physical work environment. Among the
questions to be asked are
• Where will the interface be located physically?
• Will the user be sitting, standing, or performing other tasks unrelated to the interface?
• Does the interface hardware accommodate space, light, or noise constraints?
• Are there special human factors considerations driven by environmental factors?
The goal of interface design is to define a set of interface objects and actions (and their screen
representations) that enable a user to perform all defined tasks in a manner that meets every
usability goal defined for the system.
Interface construction normally begins with the creation of a prototype that enables usage
scenarios to be evaluated. As the iterative design process continues, a user interface tool kit may
be used to complete the construction of the interface.
Interface validation focuses on (1) the ability of the interface to implement every user task
correctly, to accommodate all task variations, and to achieve all general user requirements; (2) the
degree to which the interface is easy to use and easy to learn, and (3) the users’ acceptance of
the interface as a useful tool in their work.
Subsequent passes through the process elaborate task detail, design information, and the
operational features of the interface.

4.3 INTERFACE ANALYSIS
A key tenet of all software engineering process models is: understand the problem before you
attempt to design a solution. In the case of user interface design, understanding the problem
means understanding (1) the people (end users) who will interact with the system through the
interface, (2) the tasks that end users must perform to do their work, (3) the content that is
presented as part of the interface, and (4) the environment in which these tasks will be conducted.
We examin these elements of interface analysis with the intent of establishing a solidfoundation
for the design tasks that follow.
4.3.1 User Analysis: The only way that you can get the mental image and the design model to
converge is to work to understand the users themselves as well as how these people will use the
system. Information from a broad array of sources can be used to accomplish this:
User Interviews. The most direct approach, members of the software team meet with end users
to better understand their needs, motivations, work culture, and a myriad of other issues. This can
be accomplished in one-on-one meetings or through focus groups.
Sales input. Sales people meet with users on a regular basis and can gather information that will
help the software team to categorize users and better understand their requirements.
Marketing input. Market analysis can be invaluable in the definition of market segments and an
understanding of how each segment might use the software in subtly different ways.
Support input. Support staff talks with users on a daily basis. They are the most likely source of
information on what works and what doesn’t, what users like and what they dislike, what features
generate questions and what features are easy to use.
The following set of questions will help you to better understand the users of a system:
• Are users trained professionals, technicians, clerical, or manufacturing workers?
• What level of formal education does the average user have?
• Are the users capable of learning from written materials or have they expressed a desire for
classroom training?
• Are users expert typists or keyboard phobic?
• What is the age range of the user community?
• Will the users be represented predominately by one gender?
• How are users compensated for the work they perform?
• Do users work normal office hours or do they work until the job is done?
• Is the software to be an integral part of the work users do or will it be used only occasionally?
• What is the primary spoken language among users?
• What are the consequences if a user makes a mistake using the system?
• Are users experts in the subject matter that is addressed by the system?
• Do users want to know about the technology that sits behind the interface?

Once these questions are answered, you’ll know who the end users are, what is likely to motivate
and please them, how they can be grouped into different user classes or profiles, what their mental
models of the system are, and how the user interface must be characterized to meettheir needs.
4.3.2 Task Analysis and Modeling: The goal of task analysis is to answer the following
questions:
• What work will the user perform in specific circumstances?
• What tasks and subtasks will be performed as the user does the work?
• What specific problem domain objects will the user manipulate as work is performed?
• What is the sequence of work tasks—the workflow?
• What is the hierarchy of tasks?
To answer these questions, you must use techniques that are are applied to the user interface.
Use cases. When used as part of task analysis, the use case is developed to show how an end
user performs some specific work-related task. The use case provides a basic description of one
important work task for the computer-aided design system. From it, you can extract tasks,
objects, and the overall flow of the interaction.
Task elaboration. The stepwise elaboration is (also called functional decomposition or stepwise
refinement) a mechanism for refining the processing tasks that are required for software to
accomplish some desired function.
Task analysis can be applied in two ways. An interactive, computer-based system is often used to
replace a manual or semi manual activity. To understand the tasks that must be performed to
accomplish the goal of the activity, you must understand the tasks that people currently perform
(when using a manual approach) and then map these into a similar (but not necessarily identical)
set of tasks that are implemented in the context of the user interface.
Alternatively, you can study an existing specification for a computer-based solution and derive a
set of user tasks that will accommodate the user model, the design model, and the system
perception. Regardless of the overall approach to task analysis, you must first define andclassify
tasks. Each of the major tasks can be elaborated into subtasks.
Object elaboration. Rather than focusing on the tasks that a user must perform, you can examine
the use case and other information obtained from the user and extract the physical objects that
are used by the interior designer. These objects can be categorized into classes. Attributes of each
class are defined, and an evaluation of the actions applied to each object provide a list of
operations. The user interface analysis model would not provide a literal implementation for each
of these operations. However, as the design is elaborated, the details ofeach operation are
defined.
Workflow analysis. When a number of different users, each playing different roles, makes use
of a user interface, it is sometimes necessary to go beyond task analysis and object elaboration
and apply workflow analysis. This technique allows you to understand how a work process is

completed when several people (and roles) are involved. Consider a company that intends to fully
automate the process of prescribing and delivering prescription drugs. The entire process will
revolve around a Web-based application that is accessible by physicians (or their assistants),
pharmacists, and patients. Workflow can be represented effectively with a UML swimlane diagram
(a variation on the activity diagram). See Figure 11.2
Regardless, the flow of events (shown in the figure) enables you to recognize a number of key
interface characteristics:
1. Each user implements different tasks via the interface; therefore, the look and feel of the
interface designed for the patient will be different than the one defined for pharmacists or
physicians.
2. The interface design for pharmacists and physicians must accommodate access to and display
of information from secondary information sources (e.g., access to inventory for the pharmacist
and access to information about alternative medications for the physician).
3. Many of the activities noted in the swimlane diagram can be further elaborated using task
analysis and/or object elaboration (e.g., Fills prescription could imply a mail-order delivery, a visit
to a pharmacy, or a visit to a special drug distribution center).
Hierarchical representation. A process of elaboration occurs as you begin to analyze the
interface. Once workflow has been established, a task hierarchy can be defined for each user type.
The hierarchy is derived by a stepwise elaboration of each task identified for the user. For example,
consider the following user task and subtask hierarchy.
User task: Requests that a prescription be refilled
• Provide identifying information.
• Specify name.
• Specify userid.
• Specify PIN and password.
• Specify prescription number.
• Specify date refill is required.
To complete the task, three subtasks are defined. One of these subtasks, provide identifying
information, is further elaborated in three additional sub-subtasks.

4.3.3 Analysis of Display Content: The user tasks lead to the presentation of a variety of
different types of content. For modern applications, display content can range from character-
based reports (e.g., a spreadsheet), graphical displays (e.g., a histogram, a 3-D model, a picture
of a person), or specialized information (e.g., audio or video files).
These data objects may be
(1) generated by components (unrelated to the interface) in other parts of an application, (2)
acquired from data stored in a database that is accessible from the application, or (3) transmitted
from systems external to the application in question.
During this interface analysis step, the format and aesthetics of the content (as it is displayed by
the interface) are considered. Among the questions that are asked and answered are:

• Are different types of data assigned to consistent geographic locations on the screen (e.g.,
photos always appear in the upper right-hand corner)?
• Can the user customize the screen location for content?
• Is proper on-screen identification assigned to all content?
• If a large report is to be presented, how should it be partitioned for ease of understanding?
• Will mechanisms be available for moving directly to summary information for large collections
of data?
• Will graphical output be scaled to fit within the bounds of the display device that is used?
• How will color be used to enhance understanding?
• How will error messages and warnings be presented to the user?
The answers to these (and other) questions will help you to establish requirements for content
presentation.
4.3.4 Analysis of the Work Environment: Hackos and Redish stated the importance of work
environment analysis as:
People do not perform their work in isolation. They are influenced by the activity around them, the
physical characteristics of the workplace, the type of equipment they are using, and the work
relationships they have with other people. If the products you design do not fit into the
environment, they may be difficult or frustrating to use.
4.4 INTERFACE DESIGN STEPS
Once interface analysis has been completed, all tasks (or objects and actions) required by the end
user have been identified in detail and the interface design activity commences. Interface design
is an iterative process. Although many different user interface design models (e.g., have been
proposed, all suggest some combination of the following steps:
1. Using information developed during interface analysis define interface objects and actions
(operations).
2. Define events (user actions) that will cause the state of the user interface to change. Model
this behavior.
3. Depict each interface state as it will actually look to the end user.
4. Indicate how the user interprets the state of the system from information provided through the
interface.
4.4.1 Applying Interface Design Steps: The definition of interface objects and the actions that
are applied to them is an important step in interface design. To accomplish this, user scenarios
are parsed. That is, a use case is written. Nouns (objects) and verbs (actions) are isolated to create
a list of objects and actions.

Once the objects and actions have been defined and elaborated iteratively, they are categorized
by type. Target, source, and application objects are identified. A source object (e.g., a report icon)
is dragged and dropped onto a target object (e.g., a printer icon).
When you are satisfied that all important objects and actions have been defined (for one design
iteration), screen layout is performed. Like other interface design activities, screen layout is an
interactive process in which graphical design and placement of icons, definition of descriptive
screen text, specification and titling for windows, and definition of major and minor menu items are
conducted.
4.4.2 User Interface Design Patterns: Graphical user interfaces have become so common that
a wide variety of user interface design patterns has emerged. As an example of a commonly
encountered interface design problem, consider a situation in which a user must enter one or more
calendar dates, sometimes months in advance. A vast array of interface design patterns has been
proposed over the past decade.
4.4.3 Design Issues: As the design of a user interface evolves, four common design issues
almost always surface: system response time, user help facilities, error information handling, and
command labeling
Response time. System response time is the primary complaint for many interactive applications.
In general, system response time is measured from the point at which the user performs some
control action (e.g., hits the return key or clicks a mouse) until the software responds with desired
output or action.
System response time has two important characteristics: length and variability. If system response
is too long, user frustration and stress are inevitable. Variability refers to the deviation from average
response time.
Help facilities. Almost every user of an interactive, computer-based system requires help now
and then. In most cases, however, modern software provides online help facilities that enable a
user to get a question answered or resolve a problem without leaving the interface. A number of
design issues must be addressed when a help facility is considered:
• Will help be available for all system functions and at all times during system interaction? Options
include help for only a subset of all functions and actions or help for all functions.
• How will the user request help? Options include a help menu, a special function key, or a HELP
command.
• How will help be represented? Options include a separate window, a reference to a printed
document (less than ideal), or a one- or two-line suggestion produced in a fixed screen location.
• How will the user return to normal interaction? Options include a return button displayed on the
screen, a function key, or control sequence.
• How will help information be structured? Options include a “flat” structure inwhich all information
is accessed through a keyword, a layered hierarchy of information that provides increasing detail
as the user proceeds into the structure, or the use of hypertext.

Error handling. Error messages and warnings are “bad news” delivered to users of interactive
systems when something has gone awry. At their worst, error messages and warnings impart
useless or misleading information and serve only to increase user frustration.
In general, every error message or warning produced by an interactive system should have the
following characteristics:
• The message should describe the problem in jargon that the user can understand.
• The message should provide constructive advice for recovering from the error.
• The message should indicate any negative consequences of the error (e.g., potentially
corrupted data files) so that the user can check to ensure that they have not occurred (or correct
them if they have).
• The message should be accompanied by an audible or visual cue. That is, a beep might be
generated to accompany the display of the message, or themessage might flash momentarily or
be displayed in a color that is easily recognizable as the “error color.”
• The message should be “nonjudgmental.” That is, the wording should never place blame on the
user.
Menu and command labeling. The typed command was once the most common mode of
interaction between user and system software and was commonly used for applications of every
type. Today, the use of window-oriented, point-and pick interfaces has reduced reliance on
typed commands. A number of design issues arise when typed commands or menu labels are
provided as a mode of interaction:
• Will every menu option have a corresponding command?
• What form will commands take? Options include a control sequence (e.g., alt-P), function keys,
or a typed word.
• How difficult will it be to learn and remember the commands? What can be done if a command
is forgotten?
• Can commands be customized or abbreviated by the user?
• Are menu labels self-explanatory within the context of the interface?
• Are submenus consistent with the function implied by a master menu item?
Application accessibility. As computing applications become ubiquitous, software engineers
must ensure that interface design encompasses mechanisms that enable easy access for those
with special needs. Accessibility for users (and software engineers) who may be physically
challenged is an imperative for ethical, legal, and business reasons. A variety of accessibility
guidelines - many designed for Web applications but often applicable to all types of software—
provide detailed suggestions for designing interfaces that achieve varying levels of accessibility.
Others provide specific guidelines for “assistive technology” that addresses the needs of those
with visual, hearing, mobility, speech, and learning impairments.
Internationalization. Software engineers and their managers invariably underestimate the effort
and skills required to create user interfaces that accommodate the needs of different locales and
languages. Too often, interfaces are designed for one locale and language and then jury-rigged to
work in other countries. The challenge for interface designers is to create “globalized” software.
That is, user interfacesshould be designed to accommodate a generic core of

functionality that can be deliveredto all who use the software. Localization features enable the
interface to becustomized for a specific market.
A variety of internationalization guidelines are available to software engineers. These guidelines
address broad design issues (e.g., screen layouts may differ in various markets) and discrete
implementation issues (e.g., differentalphabets may create specialized labeling and spacing
requirements). The Unicode standard has been developed to address the daunting challenge of
managingdozens of natural languages with hundreds of characters and symbols.
4.5 WEBAPP INTERFACE DESIGN
WebApp interface need to answer three primary questions for the end user:
Where am I? The interface should (1) provide an indication of the WebApp that has been
accessed and (2) inform the user of her location in the content hierarchy.
What can I do now? The interface should always help the user understand his currentoptions—
what functions are available, what links are live, what content is relevant?
Where have I been, where am I going? The interface must facilitate navigation. Hence, it must
provide a “map” of where the user has been and what paths may be taken to move elsewhere
within the WebApp. An effective WebApp interface must provide answers for each of these
questions as the end user navigates through content and functionality.
4.5.1 Interface Design Principles and Guidelines: The user interface of a WebApp is its “first
impression.” Because of the sheer volume of competing WebApps in virtually every subject area,
the interface must “grab” a potential user immediately.
Effective interfaces do not concern the user with the inner workings of the system. Effective
applications and services perform a maximum of work, while requiring a minimum of information
from users. The designer of the WebApp should anticipate that the user might request a download
of the driver and should provide navigation facilities that allow this to happen without requiring the
user to search for this capability.
Communication. The interface should communicate the status of any activity initiated by the user.
Communication can be obvious (e.g., a text message) or subtle (e.g., an image of a sheet of paper
moving through a printer to indicate that printing is under way). The interface should also
communicate user status (e.g., the user’s identification) and her location within the WebApp
content hierarchy.
Consistency. The use of navigation controls, menus, icons, and aesthetics (e.g., color,
shape, layout) should be consistent throughout the WebApp
Controlled autonomy. The interface should facilitate user movement throughout the WebApp,
but it should do so in a manner that enforces navigation conventions that have been established
for the application. For example, navigation to secure portions of the WebApp should be controlled
by userID and password.

Efficiency. The design of the WebApp and its interface should optimize the user’s work efficiency,
not the efficiency of the developer who designs and builds it or the client server environment that
executes it.
Flexibility. The interface should be flexible enough to enable some users to accomplish tasks
directly and others to explore the WebApp in a somewhat random fashion.
Focus. The WebApp interface (and the content it presents) should stay focused on the user task(s)
at hand.
Fitt’s law. “The time to acquire a target is a function of the distance to and size of the target”
If a sequence of selections or standardized inputs (with many different options within the
sequence) is defined by a user task, the first selection (e.g., mouse pick) should be physically
close to the next selection.
Human interface objects. A vast library of reusable human interface objects has been developed
for WebApps. Use them. Any interface object that can be “seen, heard, touched or otherwise
perceived” by an end user can be acquired from any one of a number of object libraries.
Latency reduction. Rather than making the user wait for some internal operation to complete
(e.g., downloading a complex graphical image), the WebApp should use multitasking in a way that
lets the user proceed with work as if the operation has been completed. In addition to reducing
latency, delays must be acknowledged so that the user understands what is happening. This
includes (1) providing audio feedback when a selection does not result in an immediate action by
the WebApp, (2) displaying an animated clock or progress bar to indicate that processing is under
way, and (3) providingsome entertainment (e.g., an animation or text presentation) while lengthy
processing occurs.
Learnability. A WebApp interface should be designed to minimize learning time, and once
learned, to minimize relearning required when the WebApp is revisited. In general the interface
should emphasize a simple, intuitive design that organizes content and functionality into
categories that are obvious to the user.
Metaphors. An interface that uses an interaction metaphor is easier to learn and easier to use, as
long as the metaphor is appropriate for the application and the user. A metaphor should call on
images and concepts from the user’s experience, but it does not need to be an exact reproduction
of a real-world experience.
Maintain work product integrity. A work product must be automatically saved so that it will not
be lost if an error occurs To avoid data loss, a WebApp should be designed to autosave all user-
specified data. The interface should support this function and provide the user with an easy
mechanism for recovering “lost” information.
Readability. All information presented through the interface should be readable by young and old.
The interface designer should emphasize readable type styles, font sizes, and color background
choices that enhance contrast.
Track state. When appropriate, the state of the user interaction should be tracked and stored so
that a user can logoff and return later to pick up where she left off. In general, cookies can be

designed to store state information. However, cookies are a controversial technology, and other
design solutions may be more palatable for some users.
Visible navigation. A well-designed WebApp interface provides “the illusion that users are in
the same place, with the work brought to them”
• Reading speed on a computer monitor is approximately 25 percent slower than reading speed
for hardcopy. Therefore, do not force the user to read voluminous amounts of text, particularly
when the text explains the operation of the WebApp or assists in navigation.
• Avoid “under construction” signs—an unnecessary link is sure to disappoint.
• Users prefer not to scroll. Important information should be placed within the dimensions of a
typical browser window.
• Navigation menus and head bars should be designed consistently and should be available on all
pages that are available to the user. The design should not rely on browser functions to assist in
navigation.
• Aesthetics should never supersede functionality. For example, a simple button might be a better
navigation option than an aesthetically pleasing, but vague image or icon whose intent is unclear.
• Navigation options should be obvious, even to the casual user. The user should not have to
search the screen to determine how to link to other content or services.
A well-designed interface improves the user’s perception of the content or services provided by
the site. It need not necessarily be flashy, but it should always be well structured and ergonomically
sound.
4.5.2 Interface Design Workflow for WebApps: Information contained within the requirements
model forms the basis for the creation of a screen layout that depicts graphical design and
placement of icons, definition of descriptive screen text, specification and titling for windows, and
specification of major and minor menu items. Tools are then used to prototype and ultimately
implement the interface design model. The following tasks represent a rudimentary workflow for
WebApp interface design:
1. Review information contained in the requirements model and refine as required.
2. Develop a rough sketch of the WebApp interface layout. An interface prototype (including
the layout) may have been developed as part of the requirements modeling activity. If the layout
already exists, it should be reviewed and refined as required. If the interface layout has not been
developed, you should work with stakeholders to develop it at this time.
3. Map user objectives into specific interface actions. For the vast majority of WebApps, the
user will have a relatively small set of primary objectives. These should be mapped into specific
interface actions as shown in Figure 11.4. In essence, you must answer the following question:
“How does the interface enable the user to accomplish each objective?”

4. Define a set of user tasks that are associated with each action. Each interface action (e.g.,
“buy a product”) is associated with a set of user tasks. These tasks have been identified during
requirements modeling. During design, they must be mapped into specific interactions that
encompass navigation issues, content objects, and WebApp functions.
5. Storyboard screen images for each interface action. As each action is considered, a
sequence of storyboard images (screen images) should be created to depict how the interface
responds to user interaction. Content objects should be identified (even if they have not yet been
designed and developed), WebApp functionality should be shown, and navigation links should be
indicated.
6. Refine interface layout and storyboards using input from aesthetic design. In most cases,
you’ll be responsible for rough layout and storyboarding, but the aesthetic look and feel for a major
commercial site is often developed by artistic, rather than technical, professionals. Aesthetic
design is integrated with the work performed by the interface designer.
7. Identify user interface objects that are required to implement the interface. This task may
require a search through an existing object library to find those reusable objects (classes) that are
appropriate for the WebApp interface. In addition, any custom classes are specified at this time.
8. Develop a procedural representation of the user’s interaction with the interface. This
optional task uses UML sequence diagrams and/or activity diagrams to depict the flow of activities
(and decisions) that occur as the user interacts with the WebApp.
9. Develop a behavioral representation of the interface. This optional task makes use of UML
state diagrams to represent state transitions and the events that cause them. Control mechanisms
(i.e., the objects and actions available to the user to alter a WebApp state) are defined.
10. Describe the interface layout for each state. Using design information developed in Tasks
2 and 5, associate a specific layout or screen image with each WebApp state described in Task
11. Refine and review the interface design model. Review of the interface should focus on
usability. It is important to note that the final task set you choose should be adapted to the
special requirements of the application that is to be built.

4.6 DESIGN EVALUATION
The user interface evaluation cycle takes the form shown in Figure 11.5. After the design model
has been completed, a first-level prototype is created. The prototype is evaluated by the user, who
provides you with direct comments about the efficacy of the interface. In addition, if formal
evaluation techniques are used (e.g., questionnaires, rating sheets), you can extract information
from these data (e.g., 80 percent of all users did not like the mechanism for saving data files).
Design modifications are made based on user input, and the next level prototype is created. The
evaluation cycle continues until no further modifications to the interface design are necessary.
The prototyping approach is effective, but is it possible to evaluate the quality of a user interface
before a prototype is built? If you identify and correct potential problems early, the number of loops
through the evaluation cycle will be reduced and development time will shorten. If a designmodel
of the interface has been created, a number of evaluation criteria can be applied during early
design reviews:
1. The length and complexity of the requirements model or written specification of the system
and its interface provide an indication of the amount of learning required by users of the system.
2. The number of user tasks specified and the average number of actions per task provide an
indication of interaction time and the overall efficiency of the system.
3. The number of actions, tasks, and system states indicated by the design model imply the
memory load on users of the system.
4. Interface style, help facilities, and error handling protocol provide a general indication of the
complexity of the interface and the degree to which it will be accepted by the user.

Once the first prototype is built, you can collect a variety of qualitative and quantitative data that
will assist in evaluating the interface. To collect qualitative data, questionnaires can be distributed
to users of the prototype. Questions can be: (1) simple yes/no response, (2) numeric response,
(3) scaled (subjective) response, (4) Likert scales (e.g., strongly agree, somewhat agree), (5)
percentage (subjective) response, or (6) open-ended.
If quantitative data are desired, a form of time-study analysis can be conducted.
4.7 WEBAPP DESIGN
What is it? Design for WebApps encompasses technical and nontechnical activities that
include: establishing the look and feel of the WebApp, creating the aesthetic layout of the user
interface, defining the overall architectural structure, developing the content and functionality
that reside within the architecture, and planning the navigation that occurs withinthe WebApp.
Who does it? Web engineers, graphic designers, content developers, and other stakeholders
all participate in the creation of a WebApp design model.
Why is it important? Design allows you to create a model that can be assessed for quality
and improved before content and code are generated, tests are conducted, and end users
become involved in large numbers. Design is the place where WebApp quality is established.
What are the steps? WebApp design encompasses six major steps that are driven by
information obtained during requirements modeling. Content design uses the content model
(developed during analysis) as the basis for establishing the design of content objects.
Aesthetic design (also called graphic design) establishes the look and feel that the end user
sees. Architectural design focuses on the overall hypermedia structure of all content objects
and functions. Interface design establishes the layout and interaction mechanisms that define
the user interface. Navigation design defines how the end user navigates through the
hypermedia structure, and component design represents the detailed internal structure of
functional elements of the WebApp.
What is the work product? A design model that encompasses content, aesthetics,
architecture, interface, navigation, and component-level design issues is the primary work
product that is produced during WebApp design
How do I ensure that I’ve done it right? Each element of the design model is reviewed in an
effort to uncover errors, inconsistencies, or omissions. In addition, alternative solutions are
considered, and the degree to which the current design model will lead to an effective
implementation is also assessed.

4.7.1 Web App Design Quality: Design is the engineering activity that leads to a high-quality
product. In fact, the user’s perception of “goodness” might be more important than any technical
discussion of WebApp quality . Olsina and his colleagues have prepared a “quality requirement
tree” that identifies a set of technical attributes—usability, functionality, reliability, efficiency, and
maintainability—that lead to high-quality WebApps. Figure 13.1 summarizes their work.
Security. WebApps have become heavily integrated with critical corporate and government
databases. E-commerce applications extract and then store sensitive customer information. For
these and many other reasons, WebApp security is paramount in many situations. The key
measure of security is the ability of the WebApp and its server environment to rebuff unauthorized
access and/or thwart an outright malevolent attack.
Availability. Even the best WebApp will not meet users’ needs if it is unavailable. In a technical
sense, availability is the measure of the percentage of time that a WebApp is available for use.
The typical end user expects WebApps to be available 24/7/365. Anything less is deemed
unacceptable.3 But “up-time” is not the only indicator of availability. Offutt suggests that “using
features available on only one browser or one platform” makes the WebApp unavailable to those
with a different browser/platform configuration. The user will invariably go elsewhere.
Scalability. Can the WebApp and its server environment be scaled to handle 100, 1000, 10,000,
or 100,000 users? Will the WebApp and the systems with which it is interfaced handle significant
variation in volume or will responsiveness drop dramatically? It is not enough to build a WebApp
that is successful. It is equally important to build a WebApp that can accommodate the burden of
success and become even more successful.

Time-to-market. Although time-to-market is not a true quality attribute in the technical sense, it
is a measure of quality from a business point of view. The first WebApp to address a specific
market segment often captures a disproportionate number of end users.
4.7.2 Design Goals: Jean Kaiser suggests a set of design goals that are applicable to virtually
every WebApp regardless of application domain, size, or complexity:
Simplicity. Better the web design should be moderation and simple. Content should be
informative but succinct and should use a delivery mode (e.g., text, graphics, video, audio) that
is appropriate to the information that is being delivered. Aesthetics should be pleasing, but not
overwhelming (e.g., too many colors tend to distract the user rather than enhancing the
interaction). Functions should be easy to use and easier to understand.
Consistency. Content should be constructed consistently. . Graphic design (aesthetics) should
present a consistent look across all parts of the WebApp. Architectural design should establish
templates that lead to a consistent hypermedia structure. Interface design should define consistent
modes of interaction, navigation, and content display. Navigation mechanisms should be used
consistently across all WebApp elements
Identity. The aesthetic, interface, and navigational design of a WebApp must be consistent with
the application domain for which it is to be built. You should work to establish an identity for the
WebApp through the design.
Robustness Based on the identity that has been established, a WebApp often makes an implicit
“promise” to a user. The user expects robust content and functions that are relevant to the user’s
needs. If these elements are missing or insufficient, it is likely that the WebApp will fail.
Navigability The navigation should be simple and consistent. It should also be designed in a
manner that is intuitive and predictable. That is, the user should understand how to move about
the WebApp without having to search for navigation links or instructions.
Visual Appeal. Beauty (visual appeal) is undoubtedly in the eye of the beholder, but many design
characteristics do contribute to visual appeal.
Compatibility. A WebApp will be used in a variety of environments and must be designed to be
compatible with each.
4.7.3 A Design Pyramid For Webapps
What is WebApp design? The creation of an effective design will typically require a diverse set
of skills. Sometimes, for small projects, a single developer may need to be multi-skilled. For
larger projects, it may be advisable and/or feasible to draw on the expertise of specialists: Web
engineers, graphic designers, content developers, programmers, database specialists,
information architects, network engineers, security experts, and testers. Drawing on these
diverse skills allows the creation of a model that can be assessed for quality and improved
before content and code are generated, tests are conducted, and end-users become involved in
large numbers. If analysis is where WebApp quality is established, then design is where the

quality is truly embedded. The appropriate mix of design skills will vary depending upon the nature
of the WebApp. Figure 13.2 depicts a design pyramid for WebApps. Each level of the pyramid
represents a design action.
4.7.4 Webapp Interface Design: One of the challenges of interface design for WebApps is the
indeterminate nature of the user’s entry point. The objectives of a WebApp interface are to: (1)
establish a consistent window into the content and functionality provided by the interface, (2) guide
the user through a series of interactions with the WebApp, and (3) organize the navigation options
and content available to the user. To achieve a consistent interface, you should first use aesthetic
design to establish a coherent “look.” This encompasses many characteristics, but must
emphasize the layout and form of navigation mechanisms. To guide user interaction, you may
draw on an appropriate metaphor5 that enables the user to gain an intuitive understanding of the
interface. To implement navigation options, you can select from one of a number of interaction
mechanisms:
• Navigation menus—keyword menus (organized vertically or horizontally) that list key content
and/or functionality. These menus may be implemented so that the user can choose from a
hierarchy of subtopics that is displayed when the primary menu option is selected.
• Graphic icons—button, switches, and similar graphical images that enable the user to select some
property or specify a decision.
• Graphic images—some graphical representation that is selectable by the user and implements
a link to a content object or WebApp functionality.

4.7.5 AESTHETIC DESIGN
Aesthetic design, also called graphic design, is an artistic endeavor that complements the
technical aspects of WebApp design. Without it, a WebApp may be functional, but unappealing.
4.7.5.1 Layout Issues: Like all aesthetic issues, there are no absolute rules when screen layout
is designed. However, a number of general layout guidelines are worth considering:
Don’t be afraid of white space. It is inadvisable to pack every square inch of a Web page with
information. The resulting clutter makes it difficult for the user to identify needed information or
features and create visual chaos that is not pleasing to the eye.
Emphasize content. After all, that’s the reason the user is there. Nielsen suggests that the typical
Web page should be 80 percent content with the remaining real estate dedicated to navigation
and other features.
Organize layout elements from top-left to bottom-right. The vast majority of users will scan a
Web page in much the same way as they scan the page of a book—top-left to bottom-right. If layout
elements have specific priorities, high-priority elements should be placed in the upper-left portion
of the page real estate.
Group navigation, content, and function geographically within the page. Humans look for
patterns in virtually all things. If there are no discernable patterns within a Web page, user
frustration is likely to increase (due to unnecessary searching for needed information).
Don’t extend your real estate with the scrolling bar. Although scrolling is often necessary, most
studies indicate that users would prefer not to scroll. It is better to reduce page content orto
present necessary content on multiple pages.
Consider resolution and browser window size when designing layout. Rather than defining
fixed sizes within a layout, the design should specify all layout items as a percentage of available
space.
4.7.5.2 Graphic Design Issues: Graphic design considers every aspect of the look and feel of a
WebApp. The graphic design process begins with layout and proceeds into a consideration of
global color schemes; text types, sizes, and styles; the use of supplementary media (e.g., audio,
video, animation); and all other aesthetic elements of an application.
4.8 CONTENT DESIGN
Content design focuses on two different design tasks. First, a design representation for content
objects and the mechanisms required to establish their relationship to one another is developed.
Second, the information within a specific content object is created.
4,8.1 Content Objects:. A content object has attributes that include content-specific information
(normally defined during WebApp requirements modeling) and implementation-specific attributes
that are specified as part of design.

4.8.2 Content Design Issues: Once all content objects are modeled, the information that each
object is to deliver must be authored and then formatted to best meet the customer’s needs.
Content authoring is the job of specialists in the relevant area who design the content object by
providing an outline of information to be delivered and an indication of the types of generic content
objects (e.g., descriptive text, graphic images, photographs) that will be used to deliver the
information. Aesthetic design may also be applied to represent the proper look and feel for the
content.
As content objects are designed, they are “chunked” to form WebApp pages. The number of
content objects incorporated into a single page is a function of user needs, constraints imposed
by download speed of the Internet connection, and restrictions imposed by the amount ofscrolling
that the user will tolerate.
4.9 ARCHITECTURE DESIGN
Content architecture focuses on the manner in which content objects (or composite objects such
as Web pages) are structured for presentation and navigation. WebApp architecture addresses
the manner in which the application is structured to manage user interaction, handle internal
processing tasks, effect navigation, and present content.
In most cases, architecture design is conducted in parallel with interface design, aestheticdesign,
and content design. Because the WebApp architecture may have a strong influence on navigation,
the decisions made during this design action will influence work conducted during navigation
design.
4.9.1 Content Architecture: The design of content architecture focuses on the definition of the
overall hypermedia structure of the WebApp. Although custom architectures are sometimes
created, you always have the option of choosing from four different content structures
Linear structures (Figure 13.4) are encountered when a predictable sequence of interactions
(with some variation or diversion) is common.
Grid structures (Figure 13.5) are an architectural option that you can apply when WebApp
content can be organized categorically in two (or more) dimensions.
Hierarchical structures (Figure 13.6) are undoubtedly the most common WebApp architecture.
A networked or “pure web” structure (Figure 13.7) is similar in many ways to the architecture that
evolves for object-oriented systems.
The architectural structures can be combined to form composite structures.

4.9.2 WebApp Architecture:. Jacyntho and his colleagues describe the basic characteristics of
this infrastructure in the following manner:
Applications should be built using layers in which different concerns are taken into account; in
particular, application data should be separated from the page’s contents (navigation nodes) and
these contents, in turn, should be clearly separated from the interface look-and-feel (pages).
The three-layer design architecture that decouples interface from navigation and from application
behavior. They argue that keeping interface, application, and navigation separate simplifies
implementation and enhances reuse. The Model-View-Controller (MVC) architecture isone of a
number of suggested WebApp infrastructure models that decouple the user interface
from the WebApp functionality and informational content. The model (sometimes referred to as the
“model object”) contains all application-specific content and processing logic, including all content
objects, access to external data/information sources, and all processing functionality that is
application specific. The view contains all interface specific functions and enables the presentation
of content and processing logic, including all content objects, access to external data/information
sources, and all processing functionality required by the end user. The controller manages access
to the model and the view and coordinates the flow of data between them. In a WebApp, “the view
is updated by the controller with data from the model based on user input”. A schematic
representation of the MVC architecture is shown in Figure 13.8.

4.10 NAVIGATION DESIGN
Once the WebApp architecture has been established and the components (pages, scripts, applets,
and other processing functions) of the architecture have been identified, you must define
navigation pathways that enable users to access WebApp content and functions. To accomplish
this, you should (1) identify the semantics of navigation for different users of the site, and (2) define
the mechanics (syntax) of achieving the navigation.
4.10.1 Navigation Semantics: Like many WebApp design actions, navigation design begins with
a consideration of the user hierarchy and related use cases developed for each category
of user (actor). Each actor may use the WebApp somewhat differently and therefore have different
navigation requirements. A series of navigation semantic units (NSUs)—“a set of information and
related navigation structures that collaborate in the fulfillment of a subset of related user
requirements. The overall navigation structure for a WebApp may be organized as a hierarchy of
NSUs.
4.10.2 Navigation Syntax: As design proceeds, your next task is to define the mechanics of
navigation. A number of options are available as you develop an approach for implementing each
NSU:
• Individual navigation link—includes text-based links, icons, buttons and switches, and graphical
metaphors. You must choose navigation links that are appropriate for the content and consistent
with the heuristics that lead to high-quality interface design.
• Horizontal navigation bar—lists major content or functional categories in a bar containing
appropriate links. In general, between four and seven categories are listed.
• Vertical navigation column—(1) lists major content or functional categories, or (2) lists virtually all
major content objects within the WebApp. If you choose the second option, such navigation
columns can “expand” to present content objects as part of a hierarchy (i.e., selecting an entry in
the original column causes an expansion that lists a second layer of related content objects).
• Tabs—a metaphor that is nothing more than a variation of the navigation bar or column,
representing content or functional categories as tab sheets that are selected when a link is
required.
• Site maps—provide an all-inclusive table of contents for navigation to all content objects and
functionality contained within the WebApp. In addition to choosing the mechanics of navigation,
you should also establish appropriate navigation conventions and aids.
4.11 COMPONENT-LEVEL DESIGN
Modern WebApps deliver increasingly sophisticated processing functions that (1) perform
localized processing to generate content and navigation capability in a dynamic fashion, (2)
provide computation or data processing capability that are appropriate for the WebApp’s business
domain, (3) provide sophisticated database query and access, and (4) establish data

interfaces with external corporate systems. To achieve these (and many other) capabilities, you
must design and construct program components that are identical in form to software components
for traditional software.
4.12 OBJECT-ORIENTED HYPERMEDIA DESIGN METHOD (OOHDM)
One of the most widely discussed WebApp design methods— OOHDM. Daniel Schwabe and
his colleagues originally proposed the Object-Oriented Hypermedia Design Method (OOHDM),
which is composed of four different design activities: conceptual design, navigational design,
abstract interface design, and implementation. A summary of these design activities is shown in
Figure 13.10
4.12.1 Conceptual Design for OOHDM: OOHDM conceptual design creates a representation
of the subsystems, classes, and relationships that define the application domain for the WebApp.
UML may be used to create appropriate class diagrams, aggregations, and composite class
representations, collaboration diagrams, and other information that describes the application
domain. The class diagrams, aggregations, and related information developed as part of WebApp
analysis are reused during conceptual design to represent relationships between classes.
4.12.2 Navigational Design for OOHDM: Navigational design identifies a set of “objects” that are
derived from the classes defined in conceptual design. A series of “navigational classes” or
“nodes” are defined to encapsulate these objects. UML may be used to create appropriate use

cases, state charts, and sequence diagrams—all representations that assist you in better
understanding navigational requirements. In addition, design patterns for navigational design may
be used as the design is developed. OOHDM uses a predefined set of navigation classes— nodes,
links, anchors, and access structures.
Access structures are more elaborate and include mechanisms such as a WebApp index, a site
map, or a guided tour.
4.12.3 Abstract Interface Design and Implementation: The abstract interface design action
specifies the interface objects that the user sees as WebApp interaction occurs. A formal model
of interface objects, called an abstract data view (ADV), is used to represent the relationship
between interface objects and navigation objects, and the behavioral characteristics of interface
objects.
The ADV model defines a “static layout” that represents the interface metaphor and includes a
representation of navigation objects within the interface and the specification of the interface
objects (e.g., menus, buttons, icons) that assist in navigation and interaction. In addition, the ADV
model contains a behavioral component that indicates how external events“trigger navigation and
which interface transformations occur when the user interacts with the application”.
The OOHDM implementation activity represents a design iteration that is specific to the
environment in which the WebApp will operate.

UNIT – 5
5.0 SOFTWARE TESTING
What is it? Software is tested to uncover errors that were made inadvertently as it was
designed and constructed.
Who does it? A strategy for software testing is developed by the project manager,software
engineers, and testing specialists.
Why is it important? Testing often accounts for more project effort than any other software
engineering action. If it is conducted haphazardly, time is wasted, unnecessary effort is
expended, and even worse, errors sneak through undetected. It would therefore seem
reasonable to establisha systematic strategy for testing software.
What are the steps? Testing begins “in the small” and progresses “to the large.” By this I
mean that early testing focuses on a single component or a small group of related
components and applies tests to uncover errors in the data and processing logic that have
been encapsulated by the component(s). After components are tested they must be
integrated until the complete system is constructed. At this point, a series of high-order tests
are executed to uncover errors in meeting customer requirements. As errors are uncovered,
they must be diagnosed and corrected using a process that is called debugging.
What is the work product? A Test Specification documents the software team’s approach
to testing by defining a plan that describes an overall strategy and a procedure that defines
specific
testing steps and the types of tests that will be conducted.
How do I ensure that I’ve done it right? By reviewing the Test Specification prior to testing,
you can assess the completeness of test casesand testing tasks. An effective test plan and
procedure will lead to the orderly construction of the software and the discovery of errors at
each stage in the construction process.
Unit V:
Software Testing Strategies: A strategic Approach to Software Testing, Strategic Issues, Test
Strategies for Conventional Software, Test Strategies for Object-Oriented Software, Test Strategies
for WebApps, Validation Testing, System Testing, The Art of Debugging.
Testing Conventional Applications: Software Testing Fundamentals, Internal and External Views
of Testing, White-Box Testing, basic Path testing, Control Structure Testing, Black-Box Testing,
Model-based Testing, Testing for Specialized Environments, Architectures and Applications,
Patterns for Software Testing.Testing Object-Oriented Applications: Broadening the View of
Testing, Testing with OOA and OOD Models, Object-Oriented Testing Strategies, Object-Oriented
Testing Methods, Testing Methods Applicable at the Class level, Interclass Test- Case Design.

5.1 A STRATEGIC APPROACH TO SOFTWARE TESTING
Testing is a set of activities that can be planned in advance and conducted systematically. A
number of software testing strategies have been proposed. All provide you with a template for
testing and all have the following generic characteristics:
• To perform effective testing, you should conduct effective technical reviews. By doing this,
many errors will be eliminated before testing commences.
• Testing begins at the component level and works “outward” toward the integration of the entire
computer-based system.
• Different testing techniques are appropriate for different software engineering approaches and
at different points in time.
• Testing is conducted by the developer of the software and an independent test group.
• Testing and debugging are different activities, but debugging must be accommodated in any
testing strategy.
A strategy for software testing must accommodate low-level tests that are necessary to verify that
a small source code segment has been correctly implemented as well as high-level tests that
validate major system functions against customer requirements.
5.1.1 Verification and Validation: Software testing is one element of a broader topic that is
often referred to as verification and validation (V&V). Verification refers to the set of tasks that
ensure that software correctly implements a specific function. Validation refers to a different set
of tasks that ensure that the software that has been built is traceable to customer requirements.
Boehm states this another way:
Verification: “Are we building the product right?”
Validation: “Are we building the right product?”
The definition of V&V encompasses many software quality assurance activities. Verification and
validation includes a wide array of SQA activities: technical reviews, quality and configuration
audits, performance monitoring, simulation, feasibility study, documentation review, database
review, algorithm analysis, development testing, usability testing, qualification testing, acceptance
testing, and installation testing.
Although testing plays an extremely important role in V&V, many other activities are also
necessary. Testing does provide the last bastion from which quality can be assessed and,
more pragmatically, errors can be uncovered
5.1.2 Organizing for Software Testing: The people who have built the software are now asked
to test the software. This seems harmless in itself; after all, who knows the program better than
its developers?
From the point of view of the builder, testing can be considered to be (psychologically) destructive.
So the builder treads lightly, designing and executing tests that will demonstrate that

the program works, rather than uncovering errors. Unfortunately, errors will be present. And, if the
software engineer doesn’t find them, the customer will. There are often a number of
misconceptions that you might infer erroneously from the preceding discussion:
(1) that the developer of software should do no testing at all,
(2) that the software should be “tossed over the wall” to strangers who will test it mercilessly,
(3) that testers get involved with the project only when the testing steps are about to begin.
Each of these statements is incorrect. The software developer is always responsible for testing
the individual units (components) of the program, ensuring that each performs the function or
exhibits the behavior for which it was designed. In many cases, the developer also conducts
integration testing—a testing step that leads to the construction (and test) of the complete
software architecture. Only after the software architecture is complete does an independent test
group become involved.
The role of an independent test group (ITG) is to remove the inherent problems associated with
letting the builder test the thing that has been built. Independent testing removes the conflict of
interest that may otherwise be present. After all, ITG personnel are paid to find errors. However,
you don’t turn the program over to ITG and walk away. The developer and the ITG work closely
throughout a software project to ensure that thorough tests will be conducted. While testing is
conducted, the developer must be available to correct errors that are uncovered.
The ITG is part of the software development project team in the sense that it becomes involved
during analysis and design and stays involved (planning and specifying test procedures)
throughout a large project. However, in many cases the ITG reports to the software quality
assurance organization, thereby achieving a degree of independence that might not be possible
if it were a part of the software engineering organization.
5.1.3 Software Testing Strategy—The Big Picture: The software process may be viewed as the
spiral illustrated in Figure 17.1. Initially, system engineering defines the role of software and leads
to software requirements analysis, where the information domain, function, behavior,performance,
constraints, and validation criteria for software are established. Moving inward along the spiral,
you come to design and finally to coding. To develop computer software, you spiral inward along
streamlines that decrease the level of abstraction on each turn.
A strategy for software testing may also be viewed in the context of the spiral (Figure 17.1). Unit
testing begins at the vortex of the spiral and concentrates on each unit (e.g., component, class,
or WebApp content object) of the software as implemented in source code. Testing progresses by
moving outward along the spiral to integration testing, where the focus is on design and the
construction of the software architecture.

Taking another turn outward on the spiral, you encounter validation testing, where requirements
established as part of requirements modeling are validated against the software that has been
constructed. Finally, you arrive at system testing, where the software and other system elements
are tested as a whole. To test computer software, you spiral out in a clockwise direction along
streamlines that broaden the scope of testing with each turn.
Considering the process from a procedural point of view, testing within the context of software
engineering is actually a series of four steps that are implemented sequentially. The steps are
shown in Figure 17.2. Initially, tests focus on each component individually, ensuring that it
functions properly as a unit. Hence, the name unit testing.
Unit testing makes heavy use of testing techniques that exercise specific paths in a component’s
control structure to ensure complete coverage and maximum error detection. Next, components
must be assembled or integrated to form the complete software package.
Integration testing addresses the issues associated with the dual problems of verification and
program construction. Test case design techniques that focus on inputs and outputs are more
prevalent during integration, although techniques that exercise specific program paths may be
used to ensure coverage of major control paths. After the software has been integrated

(constructed), a set of high-order tests is conducted. Validation criteria (established during
requirements analysis) must be evaluated.
Validation testing provides final assurance that software meets all informational, functional,
behavioral, and performance requirements.
System testing: The last high-order testing step falls outside the boundary of software engineering
and into the broader context of computer system engineering. Software, once validated, must be
combined with other system elements (e.g., hardware, people, databases). System testing verifies
that all elements mesh properly and that overall system function/performance is achieved.
5.1.4 Criteria for Completion of Testing: A classic question arises every time software testing
is discussed: “When are we done testing—how do we know that we’ve tested enough?” Sadly,
there is no definitive answer to this question, but there are a few pragmatic responses and early
attempts at empirical guidance.
One response to the question is: “You’re never done testing; the burden simply shifts from you
(the software engineer) to the end user.” Every time the user executes a computer program, the
program is being tested.
Another response is: “You’re done testing when you run out of time or you run out of money.”
Although few practitioners would argue with these responses, you need more rigorous criteria for
determining when sufficient testing has been conducted.
The clean room software engineering approach suggests statistical use techniques that execute
a series of tests derived from a statistical sample of all possible program executions by all users
from a targeted population. Others advocate using statistical modeling and software reliability
theory to predict the completeness of testing.
By collecting metrics during software testing and making use of existing software reliability models,
it is possible to develop meaningful guidelines for testing. The empirical approaches thatcurrently
exist are considerably better than raw intuition.
5.2 STRATEGIC ISSUES
Some times the best strategy will fail if a series of overriding issues are not addressed. Tom Gilb
argues that a software testing strategy will succeed when software testers: Specify product
requirements in a quantifiable manner long before testing commences.
Although the overriding objective of testing is to find errors, a good testing strategy also assesses
other quality characteristics such as portability, maintainability, and usability. These should be
specified in a way that is measurable so that testing results are unambiguous.

The specific objectives of testing should be stated in measurable terms. For example, test
effectiveness, test coverage, meantime-to-failure, the cost to find and fix defects, remaining defect
density or frequency of occurrence, and test work-hours should be stated in the test plan.
Understand the users of the software and develop a profile for each user category. Use cases that
describe the interaction scenario for each class of user can reduce overall testing effort by focusing
testing on actual use of the product.
Develop a testing plan that emphasizes “rapid cycle testing.” Gilb recommends that a software
team “learn to test in rapid cycles of customer-useful, at least field ‘trialable,’ increments of
functionality and/or quality improvement.” The feedback generated from these rapid cycle tests
can be used to control quality levels and the corresponding test strategies.
Build “robust” software that is designed to test itself. Software should be designed in a manner
that uses anti bugging techniques. That is, software should be capable of diagnosing certain
classes of errors. In addition, the design should accommodate automated testing and regression
testing.
Use effective technical reviews as a filter prior to testing. Technical reviews can be as effective as
testing in uncovering errors. For this reason, reviews can reduce the amount of testing effort that
is required to produce high quality software.
Conduct technical reviews to assess the test strategy and test cases themselves.Technical
reviews can uncover inconsistencies, omissions, and outright errors in the testing approach. This
saves time and also improves product quality.
Develop a continuous improvement approach for the testing process. The test strategy should be
measured. The metrics collected during testing should be used as part of a statistical process
control approach for software testing.
5.3 TEST STRATEGIES FOR CONVENTIONAL SOFTWARE
There are many strategies that can be used to test software. A testing strategy that is chosen by
most software teams falls between the two extremes. It takes an incremental view of testing,
beginning with the testing of individual program units, moving to tests designed to facilitate the
integration of the units, and culminating with tests that exercise the constructed system. Each of
these classes of tests is described in the sections that follow.
5.3.1 Unit Testing: Unit testing focuses verification effort on the smallest unit of software design—
the software component or module. Using the component-level design description as a guide,
important control paths are tested to uncover errors within the boundary of the module. The relative
complexity of tests and the errors those tests uncover is limited by the constrained scope
established for unit testing. The unit test focuses on the internal processing logic and data
structures within the boundaries of a component. This type of testing can be conducted in parallel
for multiple components.

Unit-test considerations. Unit tests are illustrated schematically in Figure 17.3. The module
interface is tested to ensure that information properly flows into and out of the program unit under
test. Local data structures are examined to ensure that data stored temporarily maintains its
integrity during all steps in an algorithm’s execution. All independent paths through the control
structure are exercised to ensure that all statements in a module have been executed at least
once. Boundary conditions are tested to ensure that the module operates properly at boundaries
established to limit or restrict processing. And finally, all error-handling paths are tested. Data flow
across a component interface is tested before any other testing is initiated.
Selective testing of execution paths is an essential task during the unit test. Test cases should be
designed to uncover errors due to erroneous computations, incorrect comparisons, or improper
control flow.
Boundary testing is one of the most important unit testing tasks. Software often fails at its
boundaries. That is, errors often occur when the nth element of an n-dimensional array is
processed, when the ith repetition of a loop with i passes is invoked, when the maximum or
minimum allowable value is encountered. Test cases that exercise data structure, control flow,
and data values just below, at, and just above maxima and minima are very likely to uncover errors.
A good design anticipates error conditions and establishes error-handling paths to reroute or
cleanly terminate processing when an error does occur.
Among the potential errors that should be tested when error handling is evaluated are: (1) error
description is unintelligible, (2) error noted does not correspond to error encountered, (3) error

condition causes system intervention prior to error handling, (4) exception-condition processing
is incorrect, or (5) error description does not provide enough information to assist in the location
of the cause of the error.
Unit-test procedures. Unit testing is normally considered as an adjunct to the coding step. The
design of unit tests can occur before coding begins or after source code has been generated. A
review of design information provides guidance for establishing test cases that are likely to uncover
errors in each of the categories. Each test case should be coupled with a set of expected results.
Because a component is not a stand-alone program, driver and/or stub software must often be
developed for each unit test. The unit test environment is illustrated in Figure 17.4. In most
applications a driver is nothing more than a “main program” that accepts test case data, passes
such data to the component (to be tested), and prints relevant results.
Stubs serve to replace modules that are subordinate (invoked by) the component to be tested. A
stub or “dummy subprogram” uses the subordinate module’s interface, may do minimal data
manipulation, prints verification of entry, and returns control to the module undergoing testing.
Drivers and stubs represent testing “overhead.” That is, both are software that must be written
(formal design is not commonly applied) but that is not delivered with the final software product.
If drivers and stubs are kept simple, actual overhead is relatively low. Unfortunately, many
components cannot be adequately unit tested with “simple” overhead software. In such cases,
complete testing can be postponed until the integration test step (where drivers or stubs are also
used).

Unit testing is simplified when a component with high cohesion is designed. When only one
function is addressed by a component, the number of test cases is reduced and errors can be
more easily predicted and uncovered.
5.3.2 Integration Testing: Integration testing is a systematic technique for constructing the
software architecture while at the same time conducting tests to uncover errors associated with
interfacing. The objective is to take unit-tested components and build a program structure that has
been dictated by design.
There is often a tendency to attempt non incremental integration; that is, to construct the
program using a “big bang” approach. All components are combined in advance. The entire
program is tested as a whole. Correction is difficult because isolation of causes is complicated
by the vast expanse of the entire program. Once these errors are corrected, new ones appear
and the process continues in a seemingly endless loop.
Incremental integration is the antithesis of the big bang approach. The program is constructed and
tested in small increments, where errors are easier to isolate and correct; interfaces are more
likely to be tested completely; and a systematic test approach may be applied.
Top-down integration. Top-down integration testing is an incremental approach to construction
of the software architecture. Modules are integrated by moving downward through the control
hierarchy, beginning with the main control module (main program).
Modules subordinate (and ultimately subordinate) to the main control module are incorporated into
the structure in either a depth-first or breadth-first manner. Referring to Figure 17.5, depth- first
integration integrates all components on a major control path of the program structure. Selection
of a major path is somewhat arbitrary and depends on application-specific characteristics. For
example, selecting the left-hand path, components M1, M2 , M5 would be integrated first. Next,
M8 or (if necessary for proper functioning of M2) M6 would be integrated.

Then, the central and right-hand control paths are built. Breadth-first integration incorporates all
components directly subordinate at each level, moving across the structure horizontally.
From the figure, components M2, M3, and M4 would be integrated first. The next control level,
M5, M6, and so on, follows. The integration process is performed in a series of five steps:
1. The main control module is used as a test driver and stubs are substituted for all components
directly subordinate to the main control module.
2. Depending on the integration approach selected (i.e., depth or breadth first), subordinate
stubs are replaced one at a time with actual components.
3. Tests are conducted as each component is integrated.
4. On completion of each set of tests, another stub is replaced with the real component.
5. Regression testing may be conducted to ensure that new errors have not been introduced.
The process continues from step 2 until the entire program structure is built.
The top-down integration strategy verifies major control or decision points early in the test process.
If depth-first integration is selected, a complete function of the software may be implemented and
demonstrated. Early demonstration of functional capability is a confidence builder for all
stakeholders.
Top-down strategy sounds relatively uncomplicated, but in practice, logistical problems can arise.
The most common of these problems occurs when processing at low levels in the hierarchy is
required to adequately test upper levels. Stubs replace low-level modules at the beginning of top-
down testing; therefore, no significant data can flow upward in the program structure. As a tester,
you are left with three choices:
(1) delay many tests until stubs are replaced with actual modules,
(2) develop stubs that perform limited functions that simulate the actual module, or
(3) integrate the software from the bottom of the hierarchy upward.
Bottom-up integration. Bottom-up integration testing, as its name implies, begins construction
and testing with atomic modules (i.e., components at the lowest levels in the program structure).
Because components are integrated from the bottom up, the functionality provided by components
subordinate to a given level is always available and the need for stubs is eliminated. A bottom-
up integration strategy may be implemented with the following steps:
1. Low-level components are combined into clusters (sometimes called builds) that perform a
specific software subfunction.
2. A driver (a control program for testing) is written to coordinate test case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward in the program structure.
Integration follows the pattern illustrated in Figure 17.6. Components are combined to form
clusters 1, 2, and 3. Each of the clusters is tested using a driver (shown as a dashed block).
Components in clusters 1 and 2 are subordinate to Ma. Drivers D1 and D2 are removed and the

clusters are interfaced directly to Ma. Similarly, driver D3 for cluster 3 is removed prior to
integration with module Mb. Both Ma and Mb will ultimately be integrated with component Mc, and
so forth. As integration moves upward, the need for separate test drivers lessens. In fact, if the top
two levels of program structure are integrated top down, the number of drivers can be reduced
substantially and integration of clusters is greatly simplified.
Regression testing. Each time a new module is added as part of integration testing, the software
changes. New data flow paths are established, new I/O may occur, and new control logic is
invoked. These changes may cause problems with functions that previously worked flawlessly. In
the context of an integration test strategy, regression testing is the reexecution of some subset of
tests that have already been conducted to ensure that changes have not propagated unintended
side effects.
Regression testing helps to ensure that changes (due to testing or for other reasons) do not
introduce unintended behavior or additional errors.
Regression testing may be conducted manually, by reexecuting a subset of all test cases or using
automated capture/playback tools. The regression test suite (the subset of tests to be executed)
contains three different classes of test cases:
• A representative sample of tests that will exercise all software functions.
• Additional tests that focus on software functions that are likely to be affected by the change.
• Tests that focus on the software components that have been changed.
As integration testing proceeds, the number of regression tests can grow quite large.
Smoke testing. Smoke testing is an integration testing approach that is commonly used when
product software is developed. It is designed as a pacing mechanism for time-critical projects,

allowing the software team to assess the project on a frequent basis. In essence, the smoke-
testing approach encompasses the following activities:
1. Software components that have been translated into code are integrated into a build. A build
includes all data files, libraries, reusable modules, and engineered components that are required
to implement one or more product functions.
2. A series of tests is designed to expose errors that will keep the build from properly performing
its function. The intent should be to uncover “showstopper” errors that have the highest likelihood
of throwing the software project behind schedule.
3. The build is integrated with other builds, and the entire product (in its current form) is smoke
tested daily. The integration approach may be top down or bottom up.
Smoke testing provides a number of benefits when it is applied on complex, timecritical, software
projects:
• Integration risk is minimized. Because smoke tests are conducted daily, incompatibilities and
other show-stopper errors are uncovered early, thereby reducing the likelihood of serious schedule
impact when errors are uncovered.
• The quality of the end product is improved. Because the approach is construction (integration)
oriented, smoke testing is likely to uncover functional errors as well as architectural and
component-level design errors. If these errors are corrected early, better product quality will result.
• Error diagnosis and correction are simplified. Like all integration testing approaches, errors
uncovered during smoke testing are likely to be associated with “new software increments”—that
is, the software that has just been added to the build(s) is a probable cause of a newly discovered
error.
• Progress is easier to assess. With each passing day, more of the software has been integrated
and more has been demonstrated to work. This improves team morale and gives managers a good
indication that progress is being made.
Strategic options. There has been much discussion about the relative advantages and
disadvantages of top-down versus bottom-up integration testing. In general, the advantages of
one strategy tend to result in disadvantages for the other strategy. Selection of an integration
strategy depends upon software characteristics and, sometimes, project schedule. In general, a
combined approach (sometimes called sandwich testing) that uses top-down tests for upper levels
of the program structure, coupled with bottom-up tests for subordinate levels may be the best
compromise.
As integration testing is conducted, the tester should identify critical modules. A critical module
has one or more of the following characteristics: (1) addresses several software requirements,
(2) has a high level of control (resides relatively high in the program structure), (3) is complex or
error prone, or (4) has definite performance requirements. Critical modules should be tested as
early as is possible. In addition, regression tests should focus on critical module function.

Integration test work products. An overall plan for integration of the software and a description
of specific tests is documented in a Test Specification. This work product incorporates a test plan
and a test procedure and becomes part of the software configuration. Testing is divided into
phases and builds that address specific functional and behavioral characteristics of the software.
Each of these integration test phases delineates a broad functional category within the software
and generally can be related to a specific domain within the software architecture. Therefore,
program builds (groups of modules) are created to correspond to each phase. The following criteria
and corresponding tests are applied for all test phases:
Interface integrity. Internal and external interfaces are tested as each module (or cluster) is
incorporated into the structure.
Functional validity. Tests designed to uncover functional errors are conducted.
Information content. Tests designed to uncover errors associated with local or global data
structures are conducted.
Performance. Tests designed to verify performance bounds established during software design
are conducted.
A schedule for integration, the development of overhead software, and related topics are also
discussed as part of the test plan. A brief description of overhead software (stubs and drivers)
concentrates on characteristics that might require special effort. Finally, test environment and
resources are described. Unusual hardware configurations, exotic simulators, and special test
tools or techniques are a few of many topics that may also be discussed.
The order of integration and corresponding tests at each integration step are described. A listing
of all test cases (annotated for subsequent reference) and expected results are also included.
A history of actual test results, problems, or peculiarities is recorded in a Test Report that can be
appended to the Test Specification. It is important to note, however, that an integration strategy
(contained in a test plan) and testing details (described in a test procedure) are essential
ingredients and must appear.
5.4 TEST STRATEGIES FOR OBJECT-ORIENTED SOFTWARE
Although this fundamental objective remains unchanged for object-oriented software, the nature
of object-oriented software changes both testing strategy and testing tactics.
5.4.1 Unit Testing in the OO Context: When object-oriented software is considered, theconcept
of the unit changes. Encapsulation drives the definition of classes and objects. This means that
each class and each instance of a class packages attributes (data) and the

operations that manipulate these data. An encapsulated class is usually the focus of unit testing.
However, operations (methods) within the class are the smallest testable units. Because a class
can contain a number of different operations, and a particular operation may exist as part of a
number of different classes, the tactics applied to unit testing must change.
You can no longer test a single operation in isolation but rather as part of a class. To illustrate,
consider a class hierarchy in which an operation X is defined for the superclass and is inherited by
a number of subclasses. Each subclass uses operation X, but it is applied within the contextof
the private attributes and operations that have been defined for the subclass. Because the context
in which operation X is used varies in subtle ways, it is necessary to test operation X in the context
of each of the subclasses. This means that testing operation X in a stand-alone fashion is usually
ineffective in the object-oriented context.
Class testing for OO software is the equivalent of unit testing for conventional software. Unlike unit
testing of conventional software, which tends to focus on the algorithmic detail of a module and
the data that flow across the module interface, class testing for OO software is driven by the
operations encapsulated by the class and the state behavior of the class.
5.4.2 Integration Testing in the OO Context: Because object-oriented software does not have
an obvious hierarchical control structure, traditional top-down and bottom-up integration strategies
have little meaning.
There are two different strategies for integration testing of OO systems. The first, thread-based
testing, integrates the set of classes required to respond to one input or event for the system. Each
thread is integrated and tested individually. Regression testing is applied to ensure that no side
effects occur. The second integration approach, use-based testing, begins the construction of the
system by testing those classes (called independent classes) that use very few (if any) server
classes. After the independent classes are tested, the next layer of classes, calleddependent
classes, that use the independent classes are tested. This sequence of testing layers of dependent
classes continues until the entire system is constructed.
The use of drivers and stubs also changes when integration testing of OO systems is conducted.
Drivers can be used to test operations at the lowest level and for the testing of whole groups of
classes. A driver can also be used to replace the user interface so that tests of system functionality
can be conducted prior to implementation of the interface. Stubs can be used in situations in which
collaboration between classes is required but one or more of the collaboratingclasses has not yet
been fully implemented.
Cluster testing is one step in the integration testing of OO software. Here, a cluster of collaborating
classes (determined by examining the CRC and object-relationship model) is exercised by
designing test cases that attempt to uncover errors in the collaborations.

5.5 TEST STRATEGIES FOR WEBAPPS
The strategy for WebApp testing adopts the basic principles for all software testing and applies a
strategy and tactics that are used for object-oriented systems. The following steps summarize
the approach:
1. The content model for the WebApp is reviewed to uncover errors.
2. The interface model is reviewed to ensure that all use cases can be accommodated.
3. The design model for the WebApp is reviewed to uncover navigation errors.
4. The user interface is tested to uncover errors in presentation and/or navigation mechanics.
5. Each functional component is unit tested.
6. Navigation throughout the architecture is tested.
7. The WebApp is implemented in a variety of different environmental configurations and is
tested for compatibility with each configuration.
8. Security tests are conducted in an attempt to exploit vulnerabilities in the WebApp or within its
environment.
9. Performance tests are conducted.
10. The WebApp is tested by a controlled and monitored population of end users.
The results of their interaction with the system are evaluated for content and navigation errors,
usability concerns, compatibility concerns, and WebApp reliability and performance.
Because many WebApps evolve continuously, the testing process is an ongoing activity,
conducted by support staff who use regression tests derived from the tests developed when the
WebApp was first engineered.
5.6 VALIDATION TESTING
Validation testing begins at the culmination of integration testing, when individual components
have been exercised, the software is completely assembled as a package, and interfacing errors
have been uncovered and corrected. At the validation or system level, the distinction between
conventional software, object-oriented software, and WebApps disappears. Testing focuses on
user-visible actions and user-recognizable output from the system.
Validation can be defined in many ways, but a simple (albeit harsh) definition is that validation
succeeds when software functions in a manner that can be reasonably expected by the customer.
At this point a battle-hardened software developer might protest: “Who or what is the arbiter of
reasonable expectations?” If a Software Requirements Specification has been developed, it
describes all user-visible attributes of the software and contains a ValidationCriteria section that
forms the basis for a validation-testing approach.
5.6.1 Validation-Test Criteria: Software validation is achieved through a series of tests that
demonstrate conformity with requirements. A test plan outlines the classes of tests to be
conducted, and a test procedure defines specific test cases that are designed to ensure that all

functional requirements are satisfied, all behavioral characteristics are achieved, all content is
accurate and properly presented, all performance requirements are attained, documentation is
correct, and usability and other requirements are met (e.g., transportability, compatibility, error
recovery, maintainability).
After each validation test case has been conducted, one of two possible conditions exists: (1) The
function or performance characteristic conforms to specification and is accepted or (2) a deviation
from specification is uncovered and a deficiency list is created. Deviations or errors discovered at
this stage in a project can rarely be corrected prior to scheduled delivery. It is oftennecessary to
negotiate with the customer to establish a method for resolving deficiencies.
5.6.2 Configuration Review: An important element of the validation process is a configuration
review. The intent of the review is to ensure that all elements of the software configuration have
been properly developed, are cataloged, and have the necessary detail to bolster the support
activities. The configuration review, sometimes called an audit.
5.6.3 Alpha and Beta Testing: It is virtually impossible for a software developer to foresee how
the customer will really use a program. When custom software is built for one customer, a series
of acceptance tests are conducted to enable the customer to validate all requirements. Conducted
by the end user rather than software engineers, an acceptance test can range from an informal
“test drive” to a planned and systematically executed series of tests. In fact, acceptance testing
can be conducted over a period of weeks or months, thereby uncovering cumulative errors that
might degrade the system over time.
If software is developed as a product to be used by many customers, it is impractical to perform
formal acceptance tests with each one. Most software product builders use a process called alpha
and beta testing to uncover errors that only the end user seems able to find.
The alpha test is conducted at the developer’s site by a representative group of end users. The
software is used in a natural setting with the developer “looking over the shoulder” of the users
and recording errors and usage problems. Alpha tests are conducted in a controlled environment.
The beta test is conducted at one or more end-user sites. Unlike alpha testing, the developer
generally is not present. Therefore, the beta test is a “live” application of the software in an
environment that cannot be controlled by the developer. The customer records all problems (real
or imagined) that are encountered during beta testing and reports these to the developer at regular
intervals. As a result of problems reported during beta tests, you make modifications and then
prepare for release of the software product to the entire customer base.
A variation on beta testing, called customer acceptance testing, is sometimes performed when
custom software is delivered to a customer under contract. The customer performs a series of
specific tests in an attempt to uncover errors before accepting the software from the developer.

In some cases (e.g., a major corporate or governmental system) acceptance testing can be very
formal and encompass many days or even weeks of testing.
5.7 SYSTEM TESTING
System testing is actually a series of different tests whose primary purpose is to fully exercise
the computer-based system. Although each test has a different purpose, all work to verify that
system elements have been properly integrated and perform allocated functions.
5.7.1 Recovery Testing: Many computer-based systems must recover from faults and resume
processing with little or no downtime. In some cases, a system must be fault tolerant; that is,
processing faults must not cause overall system function to cease. In other cases, a system failure
must be corrected within a specified period of time or severe economic damage will occur.
Recovery testing is a system test that forces the software to fail in a variety of ways and verifies
that recovery is properly performed. If recovery is automatic (performed by the system itself),
reinitialization, checkpointing mechanisms, data recovery, and restart are evaluated for
correctness. If recovery requires human intervention, the mean-time-to-repair (MTTR) is evaluated
to determine whether it is within acceptable limits.
5.7.2 Security Testing: Any computer-based system that manages sensitive information or
causes actions that can improperly harm (or benefit) individuals is a target for improper or illegal
penetration. Penetration spans a broad range of activities: hackers who attempt to penetrate
systems for sport, disgruntled employees who attempt to penetrate for revenge, dishonest
individuals who attempt to penetrate for illicit personal gain.
Security testing attempts to verify that protection mechanisms built into a system will, in fact,
protect it from improper penetration.
During security testing, the tester plays the role(s) of the individual who desires to penetrate the
system. Anything goes! The tester may attempt to acquire passwords through external clerical
means; may attack the system with custom software designed to break down any defenses that
have been constructed; may overwhelm the system, thereby denying service to others; may
purposely cause system errors, hoping to penetrate during recovery; may browse through insecure
data, hoping to find the key to system entry.
Given enough time and resources, good security testing will ultimately penetrate a system. The
role of the system designer is to make penetration cost more than the value of the information that
will be obtained.
5.7.3 Stress Testing: Stress testing executes a system in a manner that demands resources in
abnormal quantity, frequency, or volume. For example, (1) special tests may be designed that

generate ten interrupts per second, when one or two is the average rate, (2) input data rates may
be increased by an order of magnitude to determine how input functions will respond, (3) test cases
that require maximum memory or other resources are executed, (4) test cases that may cause
thrashing in a virtual operating system are designed, (5) test cases that may cause excessive
hunting for disk-resident data are created. Essentially, the tester attempts to break theprogram.
A variation of stress testing is a technique called sensitivity testing. In some situations (the most
common occur in mathematical algorithms), a very small range of data contained within the bounds
of valid data for a program may cause extreme and even erroneous processing or profound
performance degradation. Sensitivity testing attempts to uncover data combinations within valid
input classes that may cause instability or improper processing.
5.7.4 Performance Testing: Performance testing is designed to test the run-time performance
of software within the context of an integrated system. Performance testing occurs throughout all
steps in the testing process. Even at the unit level, the performance of an individual module may
be assessed as tests are conducted. However, it is not until all system elements are fully integrated
that the true performance of a system can be ascertained. Performance tests are often coupled
with stress testing and usually require both hardware and software instrumentation. That is, it is
often necessary to measure resource utilization (e.g., processor cycles) in an exacting fashion.
5.7.5 Deployment Testing: In many cases, software must execute on a variety of platforms and
under more than one operating system environment. Deployment testing, sometimes called
configuration testing, exercises the software in each environment in which it is to operate. In
addition, deployment testing examines all installation procedures and specialized installation
software (e.g., “installers”) that will be used by customers, and all documentation that will be used
to introduce the software to end users.
5.8 THE ART OF DEBUGGING
Debugging occurs as a consequence of successful testing. That is, when a test case uncovers an
error, debugging is the process that results in the removal of the error. Although debugging can
and should be an orderly process, it is still very much an art.
5.8.1 The Debugging Process: Debugging is not testing but often occurs as a consequence of
testing. Referring to Figure 17.7, the debugging process begins with the execution of a test case.
Results are assessed and a lack of correspondence between expected and actual performance

is encountered. In many cases, the non corresponding data are a symptom of an underlying cause
as yet hidden. The debugging process attempts to match symptom with cause, thereby leading to
error correction.
The debugging process will usually have one of two outcomes:
(1) the cause will be found and corrected or
(2) the cause will not be found.
In the latter case, the person performing debugging may suspect a cause, design a test case to
help validate that suspicion, and work toward error correction in an iterative fashion.
Why is debugging so difficult? In all likelihood, human psychology has more to do with an
answer than software technology. However, a few characteristics of bugs provide some clues:
1. The symptom and the cause may be geographically remote. That is, the symptom may appear
in one part of a program, while the cause may actually be located at a site that is far removed.
Highly coupled components exacerbate this situation.
2. The symptom may disappear (temporarily) when another error is corrected.
3. The symptom may actually be caused by non errors (e.g., round-off inaccuracies).
4. The symptom may be caused by human error that is not easily traced.
5. The symptom may be a result of timing problems, rather than processing problems.
6. It may be difficult to accurately reproduce input conditions (e.g., a real-time application in which
input ordering is indeterminate).

7. The symptom may be intermittent. This is particularly common in embedded systems that
couple hardware and software inextricably.
8. The symptom may be due to causes that are distributed across a number of tasks running on
different processors.
During debugging, you’ll encounter errors that range from mildly annoying (e.g., an incorrect output
format) to catastrophic (e.g., the system fails, causing serious economic or physical damage). As
the consequences of an error increase, the amount of pressure to find the cause also increases.
Often, pressure forces some software developers to fix one error and at the same time introduce
two more.
5.8.2 Psychological Considerations: Unfortunately, there appears to be some evidence that
debugging prowess is an innate human trait. Some people are good at it and others aren’t.
Although experimental evidence on debugging is open to many interpretations, large variances
in debugging ability have been reported for programmers with the same education and experience.
5.8.3 Debugging Strategies: In general, three debugging strategies have been proposed (1)
brute force, (2) backtracking, and (3) cause elimination. Each of these strategies can be
conducted manually, but modern debugging tools can make the process much more effective.
Debugging tactics. The brute force category of debugging is probably the most common and
least efficient method for isolating the cause of a software error. You apply brute force
debugging methods when all else fails. Using a “let the computer find the error” philosophy,
memory dumps are taken, run-time traces are invoked, and the program is loaded with output
statements. You hope that somewhere in the morass of information that is produced you’ll find a
clue that can lead to the cause of an error. Although the mass of information produced may
ultimately lead to success, it more frequently leads to wasted effort and time. Thought must be
expended first!
Backtracking is a fairly common debugging approach that can be used successfully in small
programs. Beginning at the site where a symptom has been uncovered, the source code is traced
backward (manually) until the cause is found. Unfortunately, as the number of source lines
increases, the number of potential backward paths may become unmanageably large.
The third approach to debugging—cause elimination—is manifested by induction or deduction and
introduces the concept of binary partitioning. Data related to the error occurrence are organized
to isolate potential causes. A “cause hypothesis” is devised and the aforementioned data are used
to prove or disprove the hypothesis. Alternatively, a list of all possible causes is developed and
tests are conducted to eliminate each. If initial tests indicate that a particular cause hypothesis
shows promise, data are refined in an attempt to isolate the bug.
Automated debugging. Each of these debugging approaches can be supplemented with
debugging tools that can provide you with semi automated support as debugging strategies are

attempted. Integrated development environments (IDEs) provide a way to capture some of the
language specific predetermined errors (e.g., missing end-of-statement characters, undefined
variables, and so on) without requiring compilation.” A wide variety of debugging compilers,
dynamic debugging aids (“tracers”), automatic test-case generators, and cross-reference
mapping tools are available. However, tools are not a substitute for careful evaluation based on
a complete design model and clear source code.
The people factor. Any discussion of debugging approaches and tools is incomplete without
mention of a powerful ally—other people. A fresh viewpoint, unclouded by hours of frustration, can
do wonders. A final maxim for debugging might be: “When all else fails, get help!”
5.8.4 Correcting the Error: Once a bug has been found, it must be corrected. But, as we have
already noted, the correction of a bug can introduce other errors and therefore do more harm than
good. Van Vleck suggests three simple questions that you should ask before making the
“correction” that removes the cause of a bug:
1. Is the cause of the bug reproduced in another part of the program? In many situations, a
program defect is caused by an erroneous pattern of logic that may be reproduced elsewhere.
Explicit consideration of the logical pattern may result in the discovery of other errors.
2. What “next bug” might be introduced by the fix I’m about to make? Before the correction is
made, the source code (or, better, the design) should be evaluated to assess coupling of logic and
data structures. If the correction is to be made in a highly coupled section of the program, special
care must be taken when any change is made.
3. What could we have done to prevent this bug in the first place? This question is the first step
toward establishing a statistical software quality assurance approach. If you correct the process
as well as the product, the bug will be removed from the current program and may be eliminated
from all future programs.

5.9 Testing Conventional Applications
What is it? Once source code has been generated, software must be tested to uncover
(and correct) as many errors as possible before delivery to your customer. Your goal is to
design a series of test cases that have a high likelihood of finding errors—but how? That’s
where software testing techniques enter the picture. These techniques provide systematic
guidance for designing tests that (1) exercise the internal logic and interfaces of every
software component and (2)exercise the input and output domains of the program to
uncover errors in program function, behavior, and performance.
Who does it? During early stages of testing, a software engineer performs all tests.
However, as the testing process progresses, testing specialists may become involved.
Why is it important? Reviews and other SQA actions can and do uncover errors, but they
are not sufficient. Every time the program is executed, the customer tests it! Therefore, you
have to execute the program before it gets to the customer with the specific intent of finding
and removing all errors. In order to find the highest possible number of errors, tests must
be conducted systematically and test cases must be designed using disciplined techniques.
What are the steps? For conventional applications, software is tested from two different
perspectives: (1) internal program logic is exercised using “white box” test-case design
techniques and (2) software requirements are exercised using “black box” test-case design
techniques. Use cases assist in the design of tests to uncover errors at thesoftware
validation level. In every case, the intent is to find the maximum number of errors with the
minimum amount of effort and time.
What is the work product? A set of test cases designed to exercise both internal logic,
interfaces, component collaborations, and external requirements is designed and
documented, expected results are defined, and actual results are recorded.
How do I ensure that I’ve done it right? When you begin testing, change your point of
view. Try hard to “break” the software! Design test cases in a disciplined fashion and
review the test cases you do create for thoroughness. In addition, you can evaluate test
coverage and track error detection activities.
5.9.1 SOFTWARE TESTING FUNDAMENTALS
The goal of testing is to find errors, and a good test is one that has a high probability of finding
an error. The tests themselves must exhibit a set of characteristics that achieve the goal of finding
the most errors with a minimum of effort.
Testability. James Bach provides the following definition for testability: “Software testability is
simply how easily [a computer program] can be tested.” The following characteristics lead to
testable software.

Operability. “The better it works, the more efficiently it can be tested.” If a system is designed
and implemented with quality in mind, relatively few bugs will block the execution of tests, allowing
testing to progress without fits and starts.
Observability. “What you see is what you test.” Inputs provided as part of testing produce distinct
outputs. System states and variables are visible or queriable during execution. Incorrect output
is easily identified. Internal errors are automatically detected and reported. Source code is
accessible.
Controllability. “The better we can control the software, the more the testing can be automated and
optimized.” All possible outputs can be generated through some combination of input, and I/O
formats are consistent and structured. All code is executable through some combination of input.
Software and hardware states and variables can be controlled directly by the test engineer. Tests
can be conveniently specified, automated, and reproduced.
Decomposability. “By controlling the scope of testing, we can more quickly isolate problems and
perform smarter retesting.” The software system is built from independent modules that can be
tested independently.
Simplicity. “The less there is to test, the more quickly we can test it.” The program should exhibit
functional simplicity (e.g., the feature set is the minimum necessary to meet requirements);
structural simplicity (e.g., architecture is modularized to limit the propagation of faults), and code
simplicity (e.g., a coding standard is adopted for ease of inspection and maintenance).
Stability. “The fewer the changes, the fewer the disruptions to testing.” Changes to the software
are infrequent, controlled when they do occur, and do not invalidate existing tests. The software
recovers well from failures.
Understandability. “The more information we have, the smarter we will test.” The architectural
design and the dependencies between internal, external, and shared components are well
understood. Technical documentation is instantly accessible, well organized, specific and detailed,
and accurate. Changes to the design are communicated to testers.
Test Characteristics : A good test has a high probability of finding an error. To achieve this goal,
the tester must understand the software and attempt to develop a mental picture of how the
software might fail. Ideally, the classes of failure are probed. For example, one class of potential
failure in a graphical user interface is the failure to recognize proper mouse position. A set of tests
would be designed to exercise the mouse in an attempt to demonstrate an error in mouse position
recognition.
A good test is not redundant. Testing time and resources are limited. There is no point in
conducting a test that has the same purpose as another test. Every test should have a different
purpose (even if it is subtly different).
A good test should be “best of breed”. In a group of tests that have a similar intent, time and
resource limitations may mitigate toward the execution of only a subset of these tests. In such
cases, the test that has the highest likelihood of uncovering a whole class of errors should be used.

A good test should be neither too simple nor too complex. Although it is sometimes possible to
combine a series of tests into one test case, the possible side effects associated with this approach
may mask errors. In general, each test should be executed separately.
5.9.2 INTERNAL AND EXTERNAL VIEWS OF TESTING: Any engineered product (and most
other things) can be tested in one of two ways:
(1) Knowing the specified function that a product has been designed to perform, tests can be
conducted that demonstrate each function is fully operational while at the same time searching for
errors in each function.
(2) Knowing the internal workings of a product, tests can be conducted to ensure that “all gears
mesh,” that is, internal operations are performed according to specifications and all internal
components have been adequately exercised.
The first test approach takes an external view and is called black-box testing. The second requires
an internal view and is termed white-box testing.
Black-box testing alludes to tests that are conducted at the software interface. A black-box test
examines some fundamental aspect of a system with little regard for the internal logical structure
of the software. White-box testing of software is predicated on close examination of procedural
detail. Logical paths through the software and collaborations between components are tested by
exercising specific sets of conditions and/or loops.
At first glance it would seem that very thorough white-box testing would lead to “100 percent correct
programs.” All we need do is define all logical paths, develop test cases to exercise them, and
evaluate results, that is, generate test cases to exercise program logic exhaustively. Unfortunately,
exhaustive testing presents certain logistical problems. For even small programs, the number of
possible logical paths can be very large. White-box testing should not, however, be dismissed as
impractical. A limited number of important logical paths can be selected and exercised. Important
data structures can be probed for validity.
5.9.3 WHITE-BOX TESTING: White-box testing, sometimes called glass-box testing, is a test-
case design philosophy that uses the control structure described as part of component-level design
to derive test cases. Using white-box testing methods, you can derive test cases that
(1) guarantee that all independent paths within a module have been exercised at least once,
(2) exercise all logical decisions on their true and false sides,
(3) execute all loops at their boundaries and within their operational bounds, and
(4) exercise internal data structures to ensure their validity.
5.9.4 BASIS PATH TESTING: Basis path testing is a white-box testing technique first proposed
by Tom McCabe. The basis path method enables the test-case designer to derive a logical
complexity measure of a procedural design and use this measure as a guide for defining a basis

set of execution paths. Test cases derived to exercise the basis set are guaranteed to execute
every statement in the program at least one time during testing.
5.9.4.1 Flow Graph Notation: Before we consider the basis path method, a simple notation for
the representation of control flow, called a flow graph (or program graph) must be introduced.
The flow graph depicts logical control flow using the notation illustrated in Figure 18.1. Each
structured construct has a corresponding flow graph symbol.
To illustrate the use of a flow graph, consider the procedural design representation in Figure
18.2a. Here, a flowchart is used to depict program control structure. Figure 18.2b maps the
flowchart into a corresponding flow graph (assuming that no compound conditions are contained
in the decision diamonds of the flowchart). Referring to Figure 18.2b, each circle, called a flow
graph node, represents one or more procedural statements. A sequence of process boxes and a
decision diamond can map into a single node. The arrows on the flow graph, called edges or
links, represent flow of controland are analogous to flowchart arrows. An edge must terminate at
a node, even if the node does not represent any procedural statements (e.g., see the flow graph
symbol for the if-then-else construct). Areas bounded by edges and nodes are called regions.
When counting regions, we include the area outside the graph as a region

When compound conditions are encountered in a procedural design, the generation of a flow graph
becomes slightly more complicated. A compound condition occurs when one or more Boolean
operators (logical OR, AND, NAND, NOR) is present in a conditional statement. Referring to Figure
18.3, the program design language (PDL) segment translates into the flow graph shown. Note that
a separate node is created for each of the conditions a and b in the statement IF a OR b. Each
node that contains a condition is called a predicate node and is characterized by two or more
edges emanating from it.
5.9.4.2 Independent Program Paths: An independent path is any path through the program
that introduces at least one new set of processing statements or a new condition. When stated in
terms of a flow graph, an independent path must move along at least one edge that has not
been traversed befor the path is defined. For example, a set of independent paths for the flow
graph illustrated in Figure 18.2b is
Path 1: 1-11
Path 2: 1-2-3-4-5-10-1-11
Path 3: 1-2-3-6-8-9-10-1-11
Path 4: 1-2-3-6-7-9-10-1-11
Note that each new path introduces a new edge. The path 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
is not considered to be an independent path because it is simply a combination of already specified
paths and does not traverse any new edges. Paths 1 through 4 constitute a basis set for the flow
graph in Figure 18.2b. That is, if you can design tests to force execution of these paths (a basis
set), every statement in the program will have been guaranteed to be executed at least one time
and every condition will have been executed on its true and false sides. It should be noted that the
basis set is not unique. In fact, a number of different basis sets can be derived for a given
procedural design.
How do you know how many paths to look for? The computation of cyclomatic complexity
provides the answer. Cyclomatic complexity is a software metric that provides a quantitative

measure of the logical complexity of a program. When used in the context of the basis path testing
method, the value computed for cyclomatic complexity defines the number of independent paths
in the basis set of a program and provides you with an upper bound for the number of tests that
must be conducted to ensure that all statements have been executed at least once. Cyclomatic
complexity has a foundation in graph theory and provides you with an extremely useful software
metric. Complexity is computed in one of three ways:
1. The number of regions of the flow graph corresponds to the cyclomatic complexity.
2. Cyclomatic complexity V(G) for a flow graph G is defined as
V(G) = E - N + 2
where E is the number of flow graph edges and N is the number of flow graph nodes.
3. Cyclomatic complexity V(G) for a flow graph G is also defined as
V(G) = P + 1
where P is the number of predicate nodes contained in the flow graph G.
Referring once more to the flow graph in Figure 18.2b, the cyclomatic complexity can be computed
using each of the algorithms just noted:
1. The flow graph has four regions.
2. V(G) =11 edges - 9 nodes +2 = 4.
3. V(G) =3 predicate nodes + 1 = 4.
Therefore, the cyclomatic complexity of the flow graph in Figure 18.2b is 4. More important, the
value for V(G) provides you with an upper bound for the number of independent paths that form
the basis set and, by implication, an upper bound on the number of tests that must be designed
and executed to guarantee coverage of all program statements.
5.9.4.3 Deriving Test Cases: The basis path testing method can be applied to a procedural
design or to source code. The procedure average, depicted in PDL in Figure 18.4, will be used as
an example to illustrate each step in the test-case design method. Note that average, although
an extremely simple algorithm, contains compound conditions and loops. The following steps can
be applied to derive the basis set:
1. Using the design or code as a foundation, draw a corresponding flow graph. A flow
graph is created using the symbols and construction rules. Referring to the PDL for average in
Figure 18.4, a flow graph is created by numbering those PDL statements that will be mapped
into corresponding flow graph nodes. The corresponding flow graph is shown in Figure 18.5.
2. Determine the cyclomatic complexity of the resultant flow graph. The cyclomatic
complexity V(G) is determined by applying the algorithms described in Section 18.4.2. It should
be noted that V(G) can be determined without developing a flow graph by counting all conditional
statements in the PDL (for the procedure average, compound conditions count as two) and adding
1. Referring to Figure 18.5,

V(G) = 6 regions
V(G) = 17 edges -13 nodes + 2 = 6
V(G) = 5 predicate nodes + 1 = 6
3. Determine a basis set of linearly independent paths. The value of V(G) provides the upper
bound on the number of linearly independent paths through the program control structure. In the
case of procedure average, we expect to specify six paths:

Path 1: 1-2-10-11-13
Path 2: 1-2-10-12-13
Path 3: 1-2-3-10-11-13
Path 4: 1-2-3-4-5-8-9-2-. . .
Path 5: 1-2-3-4-5-6-8-9-2-. . .
Path 6: 1-2-3-4-5-6-7-8-9-2-. . .
The ellipsis (. . .) following paths 4, 5, and 6 indicates that any path through the remainder of the
control structure is acceptable. It is often worthwhile to identify predicate nodes as an aid in the
derivation of test cases. In this case, nodes 2, 3, 5, 6, and 10 are predicate nodes.
4. Prepare test cases that will force execution of each path in the basis set. Data should be
chosen so that conditions at the predicate nodes are appropriately set as each path is tested. Each
test case is executed and compared to expected results. Once all test cases have been completed,
the tester can be sure that all statements in the program have been executed at leastonce. It is
important to note that some independent paths (e.g., path 1 in our example) cannot betested in
stand-alone fashion. That is, the combination of data required to traverse the path cannot be
achieved in the normal flow of the program. In such cases, these paths are tested as part of another
path test.
5.9.4.4 Graph Matrices: The procedure for deriving the flow graph and even determining a set
of basis paths is amenable to mechanization. A data structure, called a graph matrix, can be quite
useful for developing a software tool that assists in basis path testing.
A graph matrix is a square matrix whose size (i.e., number of rows and columns) is equal to the
number of nodes on the flow graph. Each row and column corresponds to an identified node,and
matrix entries correspond to connections (an edge) between nodes. A simple example of a flow
graph and its corresponding graph matrix is shown in Figure 18.6.

Referring to the figure, each node on the flow graph is identified by numbers, while each edge is
identified by letters. A letter entry is made in the matrix to correspond to a connection between two
nodes. For example, node 3 is connected to node 4 by edge b.
To this point, the graph matrix is nothing more than a tabular representation of a flow graph.
However, by adding a link weight to each matrix entry, the graph matrix can become a powerful
tool for evaluating program control structure during testing.
The link weight provides additional information about control flow. In its simplest form, the link
weight is 1 (a connection exists) or 0 (a connection does not exist). But link weights can be
assigned other, more interesting properties:
• The probability that a link (edge) will be execute.
• The processing time expended during traversal of a link
• The memory required during traversal of a link
• The resources required during traversal of a link.
Beizer provides a thorough treatment of additional mathematical algorithms that can be applied
to graph matrices. Using these techniques, the analysis required to design test cases can be
partially or fully automated.
5.9.5 CONTROL STRUCTURE TESTING
The basis path testing technique is one of a number of techniques for control structure testing.
Although basis path testing is simple and highly effective, it is not sufficient in itself. The other
variations on control structure testing are discussed. These broaden testing coverage and improve
the quality of white-box testing.
5.9.5.1 Condition Testing: Condition testing is a test-case design method that exercises the
logical conditions contained in a program module. A simple condition is a Boolean variable or a
relational expression, possibly preceded with one NOT (¬) operator. A relational expression takes
the form E1 <relational-operator> E2
where E1 and E2 are arithmetic expressions and <relational-operator> is one of the following:
<,>,>=,<=,!= (nonequality). A compound condition is composed of two or more simple conditions,
Boolean operators, and parentheses. We assume that Boolean operators allowed in a compound
condition include OR (|), AND (&), and NOT (¬). A condition without relational expressions is
referred to as a Boolean expression.
If a condition is incorrect, then at least one component of the condition is incorrect. Therefore,
types of errors in a condition include Boolean operator errors (incorrect/missing/extra Boolean
operators), Boolean variable errors, Boolean parenthesis errors, relational operator errors, and

arithmetic expression errors. The condition testing method focuses on testing each condition in
the program to ensure that it does not contain errors.
5.9.5.2 Data Flow Testing: The data flow testing method selects test paths of a program
according to the locations of definitions and uses of variables in the program. To illustrate the data
flow testing approach, assume that each statement in a program is assigned a unique statement
number and that each function does not modify its parameters or global variables. For a statement
with S as its statement number,
DEF(S) = {X | statement S contains a definition of X}
USE(S) = {X | statement S contains a use of X}
If statement S is an if or loop statement, its DEF set is empty and its USE set is based on the
condition of statement S. The definition of variable X at statement S is said to be live atstatement
S’ if there exists a path from statement S to statement S’ that contains no other definition of X.
A definition-use (DU) chain of variable X is of the form [X, S, S’], where S and S’ are statement
numbers, X is in DEF(S) and USE(S’), and definition of X in statement S is live at statement S’.
One simple data flow testing strategy is to require that every DU chain be covered at least once.
We refer to this strategy as the DU testing strategy. It has been shown that DU testing does not
guarantee the coverage of all branches of a program. However, a branch is not guaranteed to be
covered by DU testing only in rare situations such as if-then-else constructs in which the then
part has no definition of any variable and the else part does not exist. In this situation, the else
branch of the if statement is not necessarily covered by DU testing.
5.9.5.3 Loop Testing: Loops are the cornerstone for the vast majority of all algorithms
implemented in software. And yet, we often pay them little heed while conducting software tests.
Loop testing is a white-box testing technique that focuses exclusively on the validity of loop
constructs. Four different classes of loops can be defined: simple loops, concatenated loops,
nested loops, and unstructured loops (Figure 18.7).
Simple loops. The following set of tests can be applied to simple loops, where n is the maximum
number of allowable passes through the loop.
1. Skip the loop entirely.
2. Only one pass through the loop.
3. Two passes through the loop.
4. m passes through the loop where m < n.
5. n -1, n, n +1 passes through the loop

Nested loops. If we were to extend the test approach for simple loops to nested loops, the number
of possible tests would grow geometrically as the level of nesting increases. This would result in
an impractical number of tests. Beizer suggests an approach that will help to reduce the number
of tests:
1. Start at the innermost loop. Set all other loops to minimum values.
2. Conduct simple loop tests for the innermost loop while holding the outer loops at theirminimum
iteration parameter (e.g., loop counter) values. Add other tests for out-of-range or excluded values.
3. Work outward, conducting tests for the next loop, but keeping all other outer loops at minimum
values and other nested loops to “typical” values.
4. Continue until all loops have been tested.
Concatenated loops. Concatenated loops can be tested using the approach defined for simple
loops, if each of the loops is independent of the other. However, if two loops are concatenated and
the loop counter for loop 1 is used as the initial value for loop 2, then the loops are not independent.
When the loops are not independent, the approach applied to nested loops is recommended.
Unstructured loops. Whenever possible, this class of loops should be redesigned to reflect the
use of the structured programming constructs.
5.9.6 BLACK-BOX TESTING
Black-box testing, also called behavioral testing, focuses on the functional requirements of the
software. That is, black-box testing techniques enable you to derive sets of input conditions that
will fully exercise all functional requirements for a program. Black-box testing is not an

alternative to white-box techniques. Rather, it is a complementary approach that is likely to
uncover a different class of errors than whitebox methods.
Black-box testing attempts to find errors in the following categories: (1) incorrect or missing
functions, (2) interface errors, (3) errors in data structures or external database access, (4)
behavior or performance errors, and (5) initialization and termination errors.
Unlike white-box testing, which is performed early in the testing process, blackbox testing tends to
be applied during later stages of testing. Because black-box testing purposely disregards control
structure, attention is focused on the information domain. Tests are designed to answer the
following questions:
• How is functional validity tested?
• How are system behavior and performance tested?
• What classes of input will make good test cases?
• Is the system particularly sensitive to certain input values?
• How are the boundaries of a data class isolated?
• What data rates and data volume can the system tolerate?
• What effect will specific combinations of data have on system operation?
By applying black-box techniques, you derive a set of test cases that satisfy the following
criteria
(1) test cases that reduce, by a count that is greater than one,
the number of additional test cases that must be designed to achieve reasonable
testing, and
(2) test cases that tell you something about the presence or absence of
classes of errors, rather than an error associated only with the specific test at hand.
5.9.6.1 Graph-Based Testing Methods: The first step in black-box testing is to understand the
objects that are modeled in software and the relationships that connect these objects. Once this
has been accomplished, the next step is to define a series of tests that verify “all objects have
the expected relationship to one another”. Stated in another way, software testing begins by
creating a graph of important objects and their relationships and

then devising a series of tests that will cover the graph so that each object and relationship
is exercised and errors are uncovered.
To accomplish these steps, you begin by creating a graph—a collection of nodes that represent
objects, links that represent the relationships between objects, node weights that describe the
properties of a node (e.g., a specific data value or state behavior), and link weights that describe
some characteristic of a link.
The symbolic representation of a graph is shown in Figure 18.8a. Nodes are represented as circles
connected by links that take a number of different forms.
A directed link (represented by an arrow) indicates that a relationship moves in only one direction.
A bidirectional link, also called a symmetric link, implies that the relationship applies in both
directions. Parallel links are used when a number of different relationships are established
between graph nodes.
As a simple example, consider a portion of a graph for a word-processing application (Figure
18.8b) where
Object #1 _ newFile (menu selection)
Object #2 _ documentWindow
Object #3 _ documentText
Referring to the figure, a menu select on newFile generates a document window. The node weight
of documentWindow provides a list of the window attributes that are to be expected when the
window is generated. The link weight indicates that the window must be generated in

less than 1.0 second. An undirected link establishes a symmetric relationship between the newFile
menu selection and documentText, and parallel links indicate relationships between
documentWindow and documentText.
Transaction flow modeling. The nodes represent steps in some transaction (e.g., the steps
required to make an airline reservation using an online service), and the links represent the logical
connection between steps (e.g., flightInformationInput is followed by
validationAvailabilityProcessing). The data flow diagram can be used to assist in creating
graphs of this type.
Finite state modeling. The nodes represent different user-observable states of the software (e.g.,
each of the “screens” that appear as an order entry clerk takes a phone order), and the links
represent the transitions that occur to move from state to state (e.g., orderInformation is verified
during inventoryAvailabilityLook-up and is followed by customerBillingInformation input).
The state diagram can be used to assist in creating graphs of this type.
Data flow modeling. The nodes are data objects, and the links are the transformations that occur
to translate one data object into another. For example, the node FICA tax withheld (FTW)is
computed from gross wages (GW) using the relationship.
Timing modeling. The nodes are program objects, and the links are the sequential connections
between those objects. Link weights are used to specify the required execution times as the
program executes.
5.9.6.2 Equivalence Partitioning: Equivalence partitioning is a black-box testing method that
divides the input domain of a program into classes of data from which test cases can be derived.
An ideal test case single-handedly uncovers a class of errors (e.g., incorrect processing of all
character data) that might otherwise require many test cases to be executed before the general
error is observed.
Test-case design for equivalence partitioning is based on an evaluation of equivalence classes for
an input condition. If a set of objects can be linked by relationships that are symmetric, transitive,
and reflexive, an equivalence class is present. An equivalence class represents a set of valid or
invalid states for input conditions. Typically, an input condition is either a specific numeric value,
a range of values, a set of related values, or a Boolean condition. Equivalence classes may be
defined according to the following guidelines:
1. If an input condition specifies a range, one valid and two invalid equivalence classes are
defined.
2. If an input condition requires a specific value, one valid and two invalid equivalence classes
are defined.
3. If an input condition specifies a member of a set, one valid and one invalid equivalence class
are defined.
4. If an input condition is Boolean, one valid and one invalid class are defined.

By applying the guidelines for the derivation of equivalence classes, test cases for each input
domain data item can be developed and executed. Test cases are selected so that the largest
number of attributes of an equivalence class are exercised at once.
5.9.6.3 Boundary Value Analysis: A greater number of errors occurs at the boundaries of the
input domain rather than in the “center.” It is for this reason that boundary value analysis (BVA)
has been developed as a testing technique. Boundary value analysis leads to a selection of test
cases that exercise bounding values.
Boundary value analysis is a test-case design technique that complements equivalence
partitioning. Rather than selecting any element of an equivalence class, BVA leads to the selection
of test cases at the “edges” of the class. Rather than focusing solely on input conditions, BVA
derives test cases from the output domain as well.
Guidelines for BVA are similar in many respects to those provided for equivalence partitioning:
1. If an input condition specifies a range bounded by values a and b, test cases should be
designed with values a and b and just above and just below a and b.
2. If an input condition specifies a number of values, test cases should be developed that exercise
the minimum and maximum numbers. Values just above and below minimum and maximum are
also tested.
3. Apply guidelines 1 and 2 to output conditions. For example, assume that a temperature versus
pressure table is required as output from an engineering analysis program. Test cases should be
designed to create an output report that produces the maximum (and minimum) allowable number
of table entries.
4. If internal program data structures have prescribed boundaries (e.g., a table has a defined limit
of 100 entries), be certain to design a test case to exercise the data structure at its boundary.
Most software engineers intuitively perform BVA to some degree. By applying these guidelines,
boundary testing will be more complete, thereby having a higher likelihood for error detection.
5.9.6.4 Orthogonal Array Testing: There are many applications in which the input domain is
relatively limited. That is, the number of input parameters is small and the values that each of the
parameters may take are clearly bounded. When these numbers are very small (e.g., three input
parameters taking on three discrete values each), it is possible to consider every input permutation
and exhaustively test the input domain. However, as the number of input values grows and the
number of discrete values for each data item increases, exhaustive testing becomes impractical
or impossible.

Orthogonal array testing can be applied to problems in which the input domain is relatively small
but too large to accommodate exhaustive testing. The orthogonal array testing method is
particularly useful in finding region faults—an error category associated with faulty logic within a
software component.
To illustrate the difference between orthogonal array testing and more conventional “one input item
at a time” approaches, consider a system that has three input items, X, Y, and Z. Each of these
input items has three discrete values associated with it. There are 33 = 27 possible test cases.
Phadke suggests a geometric view of the possible test cases associated with X, Y, and Z illustrated
in Figure 18.9.
Referring to the figure, one input item at a time may be varied in sequence along each input axis.
This results in relatively limited coverage of the input domain (represented by the left-hand cube
in the figure).
When orthogonal array testing occurs, an L9 orthogonal array of test cases is created. The L9
orthogonal array has a “balancing property”. That is, test cases (represented by dark dots in the
figure) are “dispersed uniformly throughout the test domain,” as illustrated in the right-hand cube
in Figure 18.9. Test coverage across the input domain is more complete.
To illustrate the use of the L9 orthogonal array, consider the send function for a fax application.
Four parameters, P1, P2, P3, and P4, are passed to the send function.
Each takes on three discrete values. For example, P1 takes on values:
P1 =1, send it now
P1 = 2, send it one hour later
P1 = 3, send it after midnight
P2, P3, and P4 would also take on values of 1, 2, and 3, signifying other send functions.
If a “one input item at a time” testing strategy were chosen, the following sequence of tests (P1,
P2, P3, P4) would be specified: (1, 1, 1, 1), (2, 1, 1, 1), (3, 1, 1, 1), (1, 2, 1, 1), (1, 3, 1, 1), (1, 1,
2, 1), (1, 1, 3, 1), (1, 1, 1, 2), and (1, 1, 1, 3). Phadke assesses these test cases by stating:
Such test cases are useful only when one is certain that these test parameters do not interact.
They can detect logic faults where a single parameter value makes the software malfunction.
These faults are called single mode faults. This method cannot detect logic faults that cause
malfunction when two or more parameters simultaneously take certain values; that is, it cannot
detect any interactions. Thus its ability to detect faults is limited.

Given the relatively small number of input parameters and discrete values, exhaustive testing is
possible. The number of tests required is 34 = 81, large but manageable.
All faults associated with data item permutation would be found, but the effort required isrelatively
high.
The orthogonal array testing approach enables you to provide good test coverage with far fewer
test cases than the exhaustive strategy. An L9 orthogonal array for the fax send function is

Phadke assesses the result of tests using the L9 orthogonal array in the following manner:
Detect and isolate all single mode faults. A single mode fault is a consistent problem with any
level of any single parameter. For example, if all test cases of factor P1 =1 cause an error condition,
it is a single mode failure. In this example tests 1, 2 and 3 will show errors. By analyzing the
information about which tests show errors, one can identify which parametervalues cause
the fault. In this example, by noting that tests 1, 2, and 3 cause an error, one can isolate [logical
processing associated with “send it now” (P1 =1)] as the source of the error. Suchan isolation of
fault is important to fix the fault.
Detect all double mode faults. If there exists a consistent problem when specific levels of two
parameters occur together, it is called a double mode fault. Indeed, a double mode fault is an
indication of pairwise incompatibility or harmful interactions between two test parameters.
Multimode faults. Orthogonal arrays [of the type shown] can assure the detection of only single
and double mode faults. However, many multimode faults are also detected by these tests.
You can find a detailed discussion of orthogonal array testing in.
5.9.7 MODEL-BASED TESTING
Model-based testing (MBT) is a black-box testing technique that uses information contained in the
requirements model as the basis for the generation of test cases. The MBT technique requires five
steps:
1. Analyze an existing behavioral model for the software or create one: Recall that a
behavioral model indicates how software will respond to external events or stimuli. To create the
model, you should perform the steps: (1) evaluate all use cases to fully understand the sequence
of interaction within the system, (2) identify events that drive the interaction sequence and
understand how these events relate to specific objects, (3) create a sequence for each use case,
(4) build a UML state diagram for the system (e.g., see Figure 7.6), and (5) review the behavioral
model to verify accuracy and consistency.
2. Traverse the behavioral model and specify the inputs that will force the software to make
the transition from state to state. The inputs will trigger events that will cause the transition to
occur.
3. Review the behavioral model and note the expected outputs as the software makes the
transition from state to state. Recall that each state transition is triggered by an event and that
as a consequence of the transition, some function is invoked and outputs are created. For each
set of inputs (test cases) you specified in step 2, specify the expected outputs as they are
characterized in the behavioral model. “A fundamental assumption of this testing is that there is
some mechanism, a test oracle, that will determine whether or not the results of a test execution
are correct”. In essence, a test oracle establishes the basis for any determination of the
correctness of the output. In most cases, the oracle is the requirements model, but it could also be
another document or application, data recorded elsewhere, or even a human expert.

4. Execute the test cases. Tests can be executed manually or a test script can be created and
executed using a testing tool.
5. Compare actual and expected results and take corrective action as required.
MBT helps to uncover errors in software behavior, and as a consequence, it is extremely useful
when testing event-driven applications.
5.10 TESTING FOR SPECIALIZED ENVIRONMENTS, ARCHITECTURES, APPLICATIONS
Unique guidelines and approaches to testing are sometimes warranted when specialized
environments, architectures, and applications are considered.
5.10.1 Testing GUIs: Graphical user interfaces (GUIs) will present you with interesting testing
challenges. Because reusable components are now a common part of GUI development
environments, the creation of the user interface has become less time consuming and more
precise. But, at the same time, the complexity of GUIs has grown, leading to more difficulty in
the design and execution of test cases. Because many modern GUIs have the same look and feel,
a series of standard tests can be derived. Finite-state modeling graphs may be used to derive a
series of tests that address specific data and program objects that are relevant to the GUI. Because
of the large number of permutations associated with GUI operations, GUI testing should be
approached using automated tools. A wide array of GUI testing tools has appeared on the market
over the past few years.
5.10.2 Testing of Client-Server Architectures: The distributed nature of client-server
environments, the performance issues associated with transaction processing, the potential
presence of a number of different hardware platforms, the complexities of network communication,
the need to service multiple clients from a centralized (or in some cases,distributed) database,
and the coordination requirements imposed on the server all combine to make testing of client-
server architectures and the software that resides within them onsiderablymore difficult than stand-
alone applications. In fact, recent industry studies indicate a significant increase in testing time
and cost when client-server environments are developed.
In general, the testing of client-server software occurs at three different levels:
(1) Individual client applications are tested in a “disconnected” mode; the operation of the server
and the underlying network are not considered. (2) The client software and associated server
applications are tested in concert, but network operations are not explicitly exercised. (3) The
complete client-server architecture, including network operation and performance, is tested.
Although many different types of tests are conducted at each of these levels of detail, the following
testing approaches are commonly encountered for client-server applications:
• Application function tests. The functionality of client applications is tested. In essence, the
application is tested in stand-alone fashion in an attempt to uncover errors in its operation.
• Server tests. The coordination and data management functions of the server are tested.
Server performance (overall response time and data throughput) is also considered.

• Database tests. The accuracy and integrity of data stored by the server is tested. Transactions
posted by client applications are examined to ensure that data are properly stored, updated, and
retrieved. Archiving is also tested.
• Transaction tests. A series of tests are created to ensure that each class of transactions is
processed according to requirements. Tests focus on the correctness of processing and also on
performance issues (e.g., transaction processing times and transaction volume).
• Network communication tests. These tests verify that communication among the nodes of the
network occurs correctly and that message passing, transactions, and related network traffic occur
without error. Network security tests may also be conducted as part of these tests.
5.10.3 Testing Documentation and Help Facilities: The term software testing conjures images
of large numbers of test cases prepared to exercise computer programs and the data that they
manipulate. It is important to note that testing must also extend to the third element of the software
configuration—documentation.
Errors in documentation can be as devastating to the acceptance of the program as errors in data
or source code. Nothing is more frustrating than following a user guide or an online help facility
exactly and getting results or behaviors that do not coincide with those predicted by the
documentation. It is for this reason that that documentation testing should be a meaningful part of
every software test plan.
Documentation testing can be approached in two phases. The first phase, technical review,
examines the document for editorial clarity. The second phase, live test, uses the documentation
in conjunction with the actual program.
Surprisingly, a live test for documentation can be approached using techniques that are analogous
to many of the black-box testing methods discussed earlier. Graph-based testing can be used to
describe the use of the program; equivalence partitioning and boundary valueanalysis can be
used to define various classes of input and associated interactions. MBT can be used to ensure
that documented behavior and actual behavior coincide. Program usage is then tracked through
the documentation.
5.10.4 Testing for Real-Time Systems: The time-dependent, asynchronous nature of many real-
time applications adds a new and potentially difficult element to the testing mix—time. Not only
does the testcase designer have to consider conventional test cases but also event handling (i.e.,
interrupt processing), the timing of the data, and the parallelism of the tasks (processes) that
handle the data. In many situations, test data provided when a realtime system is in one state will
result in proper processing, while the same data provided when the system is in a different state
may lead to error.

In addition, the intimate relationship that exists between real-time software and its hardware
environment can also cause testing problems. Software tests must consider the impact ofhardware
faults on software processing. Such faults can be extremely difficult to simulate realistically.
Comprehensive test-case design methods for real-time systems continue to evolve. However, an
overall four-step strategy can be proposed:
• Task testing. The first step in the testing of real-time software is to test each task independently.
That is, conventional tests are designed for each task and executed independently during these
tests. Task testing uncovers errors in logic and function but not timing or behavior.
• Behavioral testing. Using system models created with automated tools, it is possible to
simulate the behavior of a real-time system and examine its behavior as a consequence of
external events. These analysis activities can serve as the basis for the design of test cases that
are conducted when the real-time software has been built. Using a technique that is similar to
equivalence partitioning, events (e.g., interrupts, control signals) are categorized for testing
Once each class of events has been tested, events are presented to the system in random order
and with random frequency. The behavior of the software is examined to detect behavior errors.
• Intertask testing. Once errors in individual tasks and in system behavior have been isolated,
testing shifts to time-related errors. Asynchronous tasks that are known to communicate withone
another are tested with different data rates and processing load to determine if intertask
synchronization errors will occur. In addition, tasks that communicate via a message queue or data
store are tested to uncover errors in the sizing of these data storage areas.
• System testing. Software and hardware are integrated, and a full range of system tests are
conducted in an attempt to uncover errors at the software hardware interface. Most real-time
systems process interrupts. Therefore, testing the handling of these Boolean events is essential.
Tests are then designed to assess the following system characteristics:
• Are interrupt priorities properly assigned and properly handled?
• Is processing for each interrupt handled correctly?
• Does the performance (e.g., processing time) of each interrupt-handling procedure conform to
requirements?
• Does a high volume of interrupts arriving at critical times create problems in function or
performance?
In addition, global data areas that are used to transfer information as part of interrupt processing
should be tested to assess the potential for the generation of side effects.
5.11 PATTERNS FOR SOFTWARE TESTING
Patterns can also be used to propose solutions to other software engineering situations—in this
case, software testing. Testing patterns describe common testing problems and solutions that can
assist you in dealing with them. Not only do testing patterns provide you with useful

guidance as testing activities commence, they also provide three additional benefits described
by Marick:
1. They [patterns] provide a vocabulary for problem-solvers. “Hey, you know, we should use a
Null Object.”
2. They focus attention on the forces behind a problem. That allows [test case] designers to
better understand when and why a solution applies.
3. They encourage iterative thinking. Each solution creates a new context in which new
problems can be solved.
Although these benefits are “soft,” they should not be overlooked. Testing patterns are described
in much the same way as design patterns. The following three testing patterns provide
representative examples:
Pattern name: PairTesting
Abstract: A process-oriented pattern, PairTesting describes a technique that is analogous
to pair programming in which two testers work together to design and execute a series of tests that
can be applied to unit, integration or validation testing activities.
Pattern name: SeparateTestInterface
Abstract: There is a need to test every class in an object-oriented system, including “internal
classes” (i.e., classes that do not expose any interface outside of the component that used them).
The SeparateTestInterface pattern describes how to create “a test interface that can be used to
describe specific tests on classes that are visible only internally to a component”.
Pattern name: ScenarioTesting
Abstract: Once unit and integration tests have been conducted, there is a need to determine
whether the software will perform in a manner that satisfies users. The ScenarioTesting pattern
describes a technique for exercising the software from the user’s point of view. A failure at this
level indicates that the software has failed to meet a user visible requirement.

5.12 TESTING OBJECT ORIENTED APPLICATIONS
What is it? The architecture of object-oriented (OO) software results in a series of layered
subsystems that encapsulate collaborating classes. Each of these system elements
(subsystems and classes) performs functions that help to achieve system requirements. It is
necessary to test an OO system at a variety of different levels in an effort to uncover errors that
may occur as classes collaborate with one another and subsystems communicate across
architectural layers.
Who does it? Object-oriented testing is performed by software engineers and testing
specialists.
Why is it important? You have to execute the program before it gets to the customer with the
specific intent of removing all errors, so that the customer will not experience the frustration
associated with a poor-quality product. In order to find the highest possible numberof errors,
tests must be conducted systematically and test cases must be designed using disciplined
techniques.
What are the steps? OO testing is strategically analogous to the testing of conventional
systems, but it is tactically different. Because the OO analysis and design models are similar in
structure and content to the resultant OO program, “testing” is initiated with the review of these
models. Once code has been generated, OO testing begins “in the small” with class testing. A
series of tests are designed that exercise class operations and examine whether errors exist
as one class collaborates with other classes. As classes are integrated to form a subsystem,
thread-based, use-based, and cluster testing along with fault-based approaches are applied to
fully exercise collaborating classes. Finally, use cases are used to uncover errors at the
software validation level.
What is the work product? A set of test cases, designed to exercise classes, their
collaborations, and behaviors is designed and documented; expected results are defined, and
actual results are recorded.
How do I ensure that I’ve done it right? When you begin testing, change your point of view.
Try hard to “break” the software! Design test cases in a disciplined fashion, and review the tests
cases you do create for thoroughness.
5.12.1.BROADENING THE VIEW OF TESTING: The construction of object-oriented software
begins with the creation of requirements (analysis) and design models. At each stage, the models
can be “tested” in an attempt to uncover errors prior to their propagation to the next iteration.
It can be argued that the review of OO analysis and design models is especially useful because
the same semantic constructs (e.g., classes, attributes, operations, messages) appear at the
analysis, design, and code levels. For example, consider a class in which a number of attributes
are defined during the first iteration of analysis. An extraneous attribute is appended to the class

(due to a misunderstanding of the problem domain). Two operations are then specified to
manipulate the attribute. A review is conducted and a domain expert points out the problem. By
eliminating the extraneous attribute at this stage, the following problems and unnecessary effort
may be avoided during analysis:
1. Special subclasses may have been generated to accommodate the unnecessary attribute or
exceptions to it. Work involved in the creation of unnecessary subclasses has been avoided.
2. A misinterpretation of the class definition may lead to incorrect or extraneous class
relationships.
3. The behavior of the system or its classes may be improperly characterized to accommodate
the extraneous attribute.
If the problem is not uncovered during analysis and propagated further, the following problems
could occur during design:
1. Improper allocation of the class to subsystem and/or tasks may occur during system design.
2. Unnecessary design work may be expended to create the procedural design for the
operations that address the extraneous attribute.
3. The messaging model will be incorrect.
During latter stages of their development, object-oriented analysis (OOA) and design (OOD)
models provide substantial information about the structure and behavior of the system. For this
reason, these models should be subjected to rigorous review prior to the generation of code.
All object-oriented models should be tested for correctness, completeness, and consistency
within the context of the model’s syntax, semantics, and pragmatics.
5.12.2 TESTING OOA AND OOD MODELS
Analysis and design models cannot be tested in the conventional sense, because they cannot
be executed. However, technical reviews can be used to examine their correctness and
consistency.
5.12.2.1 Correctness of OOA and OOD Models: The notation and syntax used to represent
analysis and design models will be tied to the specific analysis and design methods that are
chosen for the project. Hence syntactic correctness is judged on proper use of the symbology;
each model is reviewed to ensure that proper modeling conventions have been maintained.
During analysis and design, you can assess semantic correctness based on the model’s
conformance to the real-world problem domain. If the model accurately reflects the real world
then it is semantically correct. To determine whether the model does, in fact, reflect real-world
requirements, it should be presented to problem domain experts who will examine the class
definitions and hierarchy for omissions and ambiguity. Class relationships are evaluated to
determine whether they accurately reflect real-world object connections.

5.12.2.2 Consistency of Object-Oriented Models: The consistency of object-oriented models
may be judged by “considering the relationships among entities in the model. To assess
consistency, you should examine each class and its connections to other classes. The class-
responsibility-collaboration (CRC) model or an objectrelationship diagram can be used to facilitate
this activity. Each CRC card lists the class name, its responsibilities (operations), and its
collaborators. The collaborations imply a series of relationships (i.e., connections) between
classes of the OO system. The object relationship model provides a graphic representation of the
connections between classes. All of this information can be obtained from the analysis model.
To evaluate the class model the following steps have been recommended:
1. Revisit the CRC model and the object-relationship model. Cross-check to ensure that all
collaborations implied by the requirements model are properly reflected in the both.
2. Inspect the description of each CRC index card to determine if a delegated
responsibility is part of the collaborator’s definition. For example, consider a class defined for
a point-of-sale checkout system and called CreditSale. This class has a CRC index card as
For this collection of classes and collaborations, ask whether a responsibility (e.g., read credit
card) is accomplished if delegated to the named collaborator (CreditCard). That is, does the class
CreditCard have an operation that enables it to be read? In this case the answer is “yes.” The
object-relationship is traversed to ensure that all such connections are valid.
3. Invert the connection to ensure that each collaborator that is asked for service is
receiving requests from a reasonable source. For example, if the CreditCard class receives

a request for purchase amount from the CreditSale class, there would be a problem.
CreditCard does not know the purchase amount.
4. Using the inverted connections examined in step 3, determine whether other classes
might be required or whether responsibilities are properly grouped among the classes.
5. Determine whether widely requested responsibilities might be combined into a single
responsibility. For example, read credit card and get authorization occur in every situation. They
might be combined into a validate credit request responsibility that incorporates getting the credit
card number and gaining authorization.
You should apply steps 1 through 5 iteratively to each class and through each evolution of the
requirements model.
Once the design model is created, you should also conduct reviews of the system design and
the object design.. The system design is reviewed by examining the object-behavior model
developed during object-oriented analysis and mapping required system behavior against the
subsystems designed to accomplish this behavior. Concurrency and task allocation are also
reviewed within the context of system behavior. The behavioral states of the system are evaluated
to determine which exist concurrently.
The object model should be tested against the object-relationship network to ensure that all design
objects contain the necessary attributes and operations to implement the collaborations defined
for each CRC index card.
5.12.3 OBJECT-ORIENTED TESTING STRATEGIES
5.12.3.1 Unit Testing in the OO Context
When object-oriented software is considered, the concept of the unit changes. Encapsulation
drives the definition of classes and objects. This means that each class and each instance of a
class (object) packages attributes (data) and the operations (also known as methods or services)
that manipulate these data. Rather than testing an individual module, the smallest testable unit is
the encapsulated class. Because a class can contain a number of different operations and a
particular operation may exist as part of a number of different classes, the meaning of unit testing
changes dramatically.
We can no longer test a single operation in isolation (the conventional view of unit testing) but
rather, as part of a class. To illustrate, consider a class hierarchy in which an operation X() is
defined for the superclass and is inherited by a number of subclasses.
Each subclass uses operation X(), but it is applied within the context of the private attributes and
operations that have been defined for each subclass. Because the context in which operation X()
is used varies in subtle ways, it is necessary to test operation X() in the context of each of the

subclasses. This means that testing operation X() in a vacuum (the traditional unit-testing
approach) is ineffective in the object-oriented context.
Class testing for OO software is the equivalent of unit testing for conventional software. Unlike unit
testing of conventional software, which tends to focus on the algorithmic detail of a module and
the data that flows across the module interface, class testing for OO software is driven by the
operations encapsulated by the class and the state behavior of the class.
5.12.3.2 Integration Testing in the OO Context: Because object-oriented software does not
have a hierarchical control structure, conventional top-down and bottom-up integration strategies
have little meaning. In addition, integrating operations one at a time into a class (the conventional
incremental integration approach) is often impossible because of the “direct and indirect
interactions of the components that make up the class”.
There are two different strategies for integration testing of OO systems. The first, thread-based
testing, integrates the set of classes required to respond to one input or event for the system. Each
thread is integrated and tested individually. Regression testing is applied to ensure that no side
effects occur. The second integration approach, use-based testing, begins the construction of the
system by testing those classes (called independent classes) that use very few (if any) of server
classes.
After the independent classes are tested, the next layer of classes, called dependent classes, that
use the independent classes are tested. This sequence of testing layers of dependent classes
continues until the entire system is constructed. Unlike conventional integration, the use of driver
and stubs as replacement operations is to be avoided, when possible.
Cluster testing is one step in the integration testing of OO software. Here, a cluster of collaborating
classes (determined by examining the CRC and objectrelationship model) is exercised by
designing test cases that attempt to uncover errors in the collaborations.
5.12.3.3 Validation Testing in an OO Context: At the validation or system level, the details of
class connections disappear. Like conventional validation, the validation of OO software focuses
on user-visible actions and user-recognizable outputs from the system. To assist in the derivation
of validation tests, the tester should draw upon use cases that are part of the requirements model.
The use case provides a scenario that has a high likelihood of uncovered errors in user-interaction
requirements.
Conventional black-box testing methods can be used to drive validation tests. In addition, you may
choose to derive test cases from the objectbehavior model and from an event flow diagram created
as part of OOA.

5.12.4 OBJECT-ORIENTED TESTING METHODS
The architecture of object-oriented software results in a series of layered subsystems that
encapsulate collaborating classes. Each of these system elements (subsystems and classes)
performs functions that help to achieve system requirements. It is necessary to test an OO system
at a variety of different levels in an effort to uncover errors that may occur as classes collaborate
with one another and subsystems communicate across architectural layers.
Test-case design methods for object-oriented software continue to evolve. However, an overall
approach to OOtest-case design has been suggested by Berard
1. Each test case should be uniquely identified and explicitly associated with the class to be
tested.
2. The purpose of the test should be stated.
3. A list of testing steps should be developed for each test and should contain:
a. A list of specified states for the class that is to be tested
b. A list of messages and operations that will be exercised as a consequence of the test
c. A list of exceptions that may occur as the class is tested
d. A list of external conditions (i.e., changes in the environment external to the software
that must exist in order to properly conduct the test)
e. Supplementary information that will aid in understanding or implementing the test
Unlike conventional test-case design, which is driven by an input-process-output view of
software or the algorithmic detail of individual modules, object-oriented testing focuses on
designing appropriate sequences of operations to exercise the states of a class.
5.12.4.1 The Test-Case Design Implications of OO Concepts: As a class evolves through the
requirements and design models, it becomes a target for test-case design. Because attributes and
operations are encapsulated, testing operations outside of the class is generally unproductive.
Although encapsulation is an essential design concept for OO, it can create a minor obstacle when
testing. As Binder notes, “Testing requires reporting on the concrete and abstract state of an
object.” Yet, encapsulation can make this information somewhat difficult to obtain. Unless built-in
operations are provided to report the values for class attributes, a snapshot of the state of an
object may be difficult to acquire.
Inheritance may also present you with additional challenges during test-case design. It is
already noted that each new usage context requires retesting, even though reuse has been
achieved. In addition, multiple inheritance4 complicates testing further by increasing the number
of contexts for which testing is required. If subclasses instantiated from a superclass are used
within the same problem domain, it is likely that the set of test cases derived for the superclass
can be used when testing the subclass. However, if the subclass is used in an entirely different
context, the superclass test cases will have little applicability and a new set of tests must be
designed.

5.12.4.2 Applicability of Conventional Test-Case Design Methods: The white-box testing
methods can be applied to the operations defined for a class. Basis path, loop testing, or data flow
techniques can help to ensure that every statement in an operation has been tested. However, the
concise structure of many class operations causes some to argue that the effort applied to white-
box testing might be better redirected to tests at a class level. Black-box testing methods are as
appropriate for OO systems as they are for systems developed using conventional software
engineering methods.
5.12.4.3 Fault-Based Testing: The object of fault-based testing within an OO system is to design
tests that have a high likelihood of uncovering plausible faults. Because the product or system
must conform to customer requirements, preliminary planning required to perform faultbased
testing begins with the analysis model. The tester looks for plausible faults. To determine whether
these faults exist, test cases are designed to exercise the design or code. Of course, the
effectiveness of these techniques depends on how testers perceive a plausible fault. If real faults
in an OO system are perceived to be implausible, then this approach is really no better than any
random testing technique. However, if the analysis and design models can provide insight into
what is likely to go wrong, then fault-based testing can find significant numbers of errors with
relatively low expenditures of effort.
Integration testing looks for plausible faults in operation calls or message connections. Three types
of faults are encountered in this context: unexpected result, wrong operation/message used, and
incorrect invocation. To determine plausible faults as functions (operations) are invoked, the
behavior of the operation must be examined. Integration testing applies to attributes as well as
to operations. The “behaviors” of an object are defined by the values that its attributes are
assigned. Testing should exercise the attributes to determine whether proper values occur for
distinct types of object behavior.
It is important to note that integration testing attempts to find errors in the client object, not the
server. Stated in conventional terms, the focus of integration testing is to determine whether errors
exist in the calling code, not the called code. The operation call is used as a clue, a way tofind test
requirements that exercise the calling code.
5.12.4.4 Test Cases and the Class Hierarchy: Inheritance complicate the testing process.
Consider the following situation. A class Base contains operations inherited() and redefined().
A class Derived redefines redefined() to serve in a local context.
It is important to note, however, that only a subset of all tests for Derived::inherited() may have
to be conducted. If part of the design and code for inherited() does not depend on redefined(), that
code need not be retested in the derived class. Base::redefined() and Derived::redefined() are two
different operations with different specifications and implementations. Each would havea set of
test requirements derived from the specification and implementation. Those test

requirements probe for plausible faults: integration faults, condition faults, boundary faults, and
so forth. But the operations are likely to be similar. Their sets of test requirements will overlap.
The better the OO design, the greater is the overlap. New tests need to be derived only for those
Derived::redefined() requirements that are not satisfied by the Base::redefined() tests. Testinputs
may be appropriate for both base and derived classes, but the expected results may differ in the
derived class.
5.12.4.5 Scenario-Based Test Design: Fault-based testing misses two main types of errors:
(1) incorrect specifications and
(2) interactions among subsystems.
When errors associated with an incorrect specification occur, the product doesn’t do what the
customer wants. It might do the wrong thing or omit important functionality. But in either
circumstance, quality (conformance to requirements) suffers. Errors associated with subsystem
interaction occur when the behavior of one subsystem creates circumstances (e.g., events, data
flow) that cause another subsystem to fail.
Scenario-based testing concentrates on what the user does, not what the product does. This
means capturing the tasks (via use cases) that the user has to perform and then applying them
and their variants as tests.
Scenarios uncover interaction errors. But to accomplish this, test cases must be more complex
and more realistic than fault-based tests. Scenario-based testing tends to exercise multiple
subsystems in a single test (users do not limit themselves to the use of one subsystem at a time.
5.12.4.6 Testing Surface Structure and Deep Structure: Surface structure refers to the
externally observable structure of an OO program. That is, the structure that is immediately
obvious to an end user. Rather than performing functions, the users of many OO systems may be
given objects to manipulate in some way.
For example, in a conventional system with a command-oriented interface, the user might use
the list of all commands as a testing checklist. In an object-based interface, the tester might use
the list of all objects as a testing checklist. The best tests are derived when the designer looks at
the system in a new or unconventional way.
Deep structure refers to the internal technical details of an OO program, that is, the structure that
is understood by examining the design and/or code. Deep structure testing is designed to exercise
dependencies, behaviors, and communication mechanisms that have been established as part of
the design model for OO software.

The requirements and design models are used as the basis for deep structure testing. For
example, the UML collaboration diagram or the deployment model depicts collaborations between
objects and subsystems that may not be externally visible.
5.12.5 TESTING METHODS APPLICABLE AT THE CLASS LEVEL
Testing “in the small” focuses on a single class and the methods that are encapsulated by the
class. Random testing and partitioning are methods that can be used to exercise a class during
OO testing.
5.12.5.1 Random Testing for OO Classes: To provide brief illustrations of these methods,
consider a banking application in which an Account class has the following operations: open(),
setup(), deposit(), withdraw(), balance(), summarize(), creditLimit(), and close(). Each of these
operations may be applied for Account, but certain constraints are implied by the nature of the
problem. Even with these constraints, there are many permutations of the operations.
5.12.5.2 Partition Testing at the Class Level: Partition testing reduces the number of test cases
required to exercise the class in much the same manner as equivalence partitioning for traditional
software. Input and output are categorized and test cases are designed to exercise each category.
But how are the partitioning categories derived?
State-based partitioning categorizes class operations based on their ability to change the state
of the class.
Attribute-based partitioning categorizes class operations based on the attributes that they use. For
the Account class, the attributes balance and creditLimit can be used to define partitions.
Operations are divided into three partitions: (1) operations that use creditLimit, (2) operations that
modify creditLimit, and (3) operations that do not use or modify creditLimit. Test sequences are
then designed for each partition.
Category-based partitioning categorizes class operations based on the generic function that each
performs. For example, operations in the Account class can be categorized in initialization
operations (open, setup), computational operations (deposit, withdraw), queries (balance,
summarize, creditLimit), and termination operations (close).
5.13 INTERCLASS TEST-CASE DESIGN
Test-case design becomes more complicated as integration of the object-oriented system begins.
It is at this stage that testing of collaborations between classes must begin.
Like the testing of individual classes, class collaboration testing can be accomplished by applying
random and partitioning methods, as well as scenario-based testing and behavioral testing.

5.13.1 Multiple Class Testing: Kirani and Tsai suggest the following sequence of steps to
generate multiple class random test cases:
1. For each client class, use the list of class operations to generate a series of random test
sequences. The operations will send messages to other server classes.
2. For each message that is generated, determine the collaborator class and the corresponding
operation in the server object.
3. For each operation in the server object (that has been invoked by messages sent from the
client object), determine the messages that it transmits.
4. For each of the messages, determine the next level of operations that are invoked and
incorporate these into the test sequence.
5.13.2 Tests Derived from Behavior Models: The use of the state diagram as a model that
represents the dynamic behavior of a class. Figure 19.3 illustrates a state diagram for the Account
class.
The tests to be designed should achieve coverage of every state. That is, the operation sequences
should cause the Account class to make transition through all allowable states:

Still more test cases could be derived to ensure that all behaviors for the class have been
adequately exercised.
The state model can be traversed in a “breadth-first” manner. In this context, breadth-first implies
that a test case exercises a single transition and that when a new transition is to be tested only
previously tested transitions are used.

G. PULLAIAH COLLEGE OF ENGINEERING AND TECHNOLOGY: KURNOOL
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Subject : SOFTWARE ENGINEERING Code : 15A05401
B.Tech. II Year-II Semester (R15) Two Marks Questions
UNIT - 1
1. Define software?
Software can be defined as follows:
 Instructions or computer programs that when executed provide desired
features, function & performance.
 Data structures that enable the programs to adequately manipulate operation.
 Documents (descriptive information) in both hard copy and virtual forms that
describes the operation and use of the programs.
2. What is Software Engineering? What are its applications?
Software Engineering: (1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that is, the
application of engineering to software.
Applications are:
 Business Process Re-Engineering.
 Communication Networks.
 Computer Graphics.
 Cooperative Work Support.
 e-Commerce.
 Education.
 Embedded Systems Programming.
 m-Commerce.
3. List out the characteristics of software?
The software quality model identifies 6 main quality characteristics, namely:
 Functionality.
 Reliability.
 Usability.
 Efficiency.
 Maintainability.
 Portability.

4. Draw software and hardware failure rate curves as a function of time?
Fig: Hardware failure rate as a function of time BATH TUB CURVE
Fig: Software Failure Curve
5. List out the types of software?
The various types of the software are:
System Software
Application Software
Engineering /Scientific software
Embedded Software
Product line software
Web Applications
Artificial Intelligence software
6. What are the layers of software engineering?

7. What is software process? Give its importance.
A software process is a set of activities, methods, practices, and transformations that
people use to develop and maintain software and the associated products (e.g.,
project plans, design documents, code, test cases, and user manuals)
Process being a fundamental tool for carrying out community consensus and
facilitating very large number of people to work together on a collaborative project
8. What are the elements of generic process framework?
A generic process framework for software engineering encompasses five activities:
• Communication
• Planning
• Modelling (Analyze, Design)
• Construction (Code, Test)
• Deployment
9. Define a software myth? List out the types of software myths?
Definition: Beliefs about software and the process used to build it. Myths have number
of attributes that have made them insidious (i.e. dangerous).
□ Misleading Attitudes - caused serious problem for managers and technical
people.
There are three types of myths:
1. Management myths
2. Customer myths
3. Practitioner myths
10. Define a software pattern?
A process pattern
i. Describes a process-related problem that is encountered during software engineering
work,
ii. Identifies the environment in which the problem has been encountered, and
iii. Suggests one or more proven solutions to the problem.
11. List out the types of process flows?
They are 4 types of process flows
i. Linear Process flow
ii. Iterative Process flow
iii. Evolutionary Process flow
iv. Parallel process flow
12. What is legacy software? What are the characteristics of legacy software?
Definition: Legacy software is old software that is still useful
Characteristics:
a. It cannot be simply discarded because it contains experienced and validated knowledge
b. It was developed to answer precise needs that are not covered by existing software
c. The system might be running on old hardware.
d. The system might be currently used by other people

13. List out the prescriptive process models for the development of software?
The list of prescriptive models is:
1. Waterfall model
2. V-model
3. Incremental model
4. Evolutionary models: Prototyping model, Spiral model and Concurrent model
14. What are the advantages of waterfall model?
Advantages of waterfall model:
i. Simple and Easy to understand and implement.
ii. Reinforces good habits: define-before- design, design-before-code
iii. Phases are processed and completed one at a time.
iv. Works well for smaller projects where requirements are very well understood.
15. What are the advantages of Prototype model?
Advantages of Prototype model:
i. Users are actively involved in the development
ii. Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
iii. Errors can be detected much earlier.
iv. Quicker user feedback is available leading to better solutions.
v. Missing functionality can be identified easily
16. What are the different phases of unified process?
17. Define the roles in scrum?
There are three roles in the Scrum method of software development:
Product Owner
ScrumMaster, and
The team.
18. What is an Agile Process?
Agile SDLC model is a combination of iterative and incremental process models with focus on
process adaptability and customer satisfaction by rapid delivery of working software product.
Agile Methods break the product into small incremental builds. These builds are provided in
iterations.

Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In agile the tasks are divided to time
boxes (small time frames) to deliver specific features for a release.Iterative approach is taken and
working software build is delivered after each iteration. Each build is incremental in terms of
features; the final build holds all the features required by the customer.
19. Differentiate between personal software process and team software process model
Personal software process model (PSP): PSP measures the work product that is produced and
results the quality of the product. The psp model defines 5 framework activities
Planning ---> High level design ---> High level design review ---> Development --->Postmortem
Team software process model (TSP) : The goal of TSP is to build a “self-directed” project team
that organizes itself to produce high quality software.TSP has following framework activities:
Project launch--->High level design--->Implementation--->Integration & Test--->Postmortem
UNIT – 2
1. State Characteristics of SRS document
Software requirement specification (SRS) is a document that completely describes what the
proposed software should do without describing how software will do it. The basic goal of
the requirement phase is to produce the SRS, Which describes the complete behavior of the
proposed software. SRS is also helping the clients to understand their own needs.
Characteristics of an SRS:
1. Correct
2. Complete
3. Unambiguous
4. Verifiable
5. Consistent
6. Ranked for importance and/or stability
7. Modifiable
8. Traceable
2. Discuss about class based modeling
Class-based elements
i. Implied by scenarios – each usage scenario implies a set of objects that are
manipulated as an actor interacts with the system. These objects are categorized
into classes.
ii. Class diagrams depicting classes, their attributes and relationships between classes
are developed.
iii. Collaboration diagrams are developed to depict the collaboration of classes

3.Discuss the role of developer in negotiating requirements of the system to be developed. The
objective of this phase is to agree on a deliverable system that is realistic for developers and
customers.
i. Conflicting requirements of customers, end-users and stake holders are reconciled.
ii. Iterative process for – requirements prioritization, risk analysis, cost estimation etc.
Roles are:
i. Identify the key stakeholders
- These are the people who will be involved in the negotiation
ii. Determine each of the stakeholders “win conditions”
- Win conditions are not always obvious
iii. Negotiate
- Work toward a set of requirements that lead to “win-win”
4. Why scenario based modeling is getting popular in the field of requirements modeling
Scenario-based elements
i. Using scenario-based approach the system is described from the user’s point of
view.
ii. Use-case—descriptions of the interaction between an “actor” and the system are
developed.
iii. Activity diagrams and swim-lane diagrams can be developed to complement use-
case diagrams.
5. Discuss analysis patterns of requirement engineering?
i. Certain problems reoccur across all projects within a specific application domain.
These analysis patterns suggest solutions within the application domain that can be
reused when modeling many applications.
ii. Analysis patterns are integrated into the analysis model by reference to the pattern
name.
iii. They are also stored in a repository so that requirements engineers can uses search
facilities to find and apply them.
6. Identify goals of elicitation phase?
The goal of elicitation phase is:
i. to identify the problem
ii. propose elements of the solution
iii. negotiate different approaches, and
iv. specify a preliminary set of solution requirements
7. Explain the process of validating requirements?
In this phase a review mechanism adapted that looks for
i. errors in content or interpretation
ii. areas where clarification may be required
iii. missing information
iv. inconsistencies (a major problem when large products or systems are
engineered)
v. conflicting or unrealistic (unachievable) requirements.

8. Illustrate ‘dependency’ relationship of class diagrams?
A dependency is a semantic connection between dependent and independent model elements.
It exists between two elements if changes to the definition of one element (the server or target)
may cause changes to the other (the client or source). This association is uni-directional.
9. Explain ‘aggregation’ relationship of class diagrams with the help of an example?
Aggregation is a variant of the "has a" association relationship; aggregation is more specific than
association. It is an association that represents a part-whole or part-of relationship. As shown in
the image, a Professor 'has a' class to teach. As a type of association, an aggregation can be
named and have the same adornments that an association can
10. Explain ‘Association’ relationship of class diagrams with an example?
An association represents a family of links. A binary association (with two ends) is normally
represented as a line. An association can link any number of classes. An association with three
links is called a ternary association. An association can be named, and the ends of an association
can be adorned with role names, ownership indicators, multiplicity, visibility, and other
properties.
11. Illustrate ‘Generalization’ relationship of class diagrams?
The generalization relationship is also known as the inheritance or "is a" relationship.
It indicates that one of the two related classes (the subclass) is considered to be a specialized
form of the other (the super type) and the superclass is considered a Generalization of the
subclass. In practice, this means that any instance of the subtype is also an instance of the
superclass.
12. What is Requirement Engineering and Software Requirement Engineering?
Requirements Engineering: Requirements Engineering builds a bridge to design and
construction.
The broad spectrum of tasks and techniques that lead to an understanding of requirements is
called Requirements Engineering.
Software Requirement Engineering: Requirements analysis, also called requirements
engineering, is the process of determining user expectations for a new or modified product.

These features, called requirements, must be quantifiable, relevant and detailed. In software
engineering, such requirements are often called functional specifications.
13. Discuss the role of use cases in UML
Use Case Diagrams: Use case diagrams are usually referred to as behavior diagrams used to
describe a set of actions (use cases) that some system or systems (subject) should or can
perform in collaboration with one or more external users of the system (actors).
Actors are the different people ( or devices) play as the system operates. Every actor has
one or more goals when using the system.
UNIT – 3
1. List out software quality attributes
a. Functionality: is assessed by evaluating the features set, the generality of the functions that
are delivered, and the security of the overall system.
b. Usability: is assessed by considering human factors, overall aesthetics, consistency, and
documentation.
c. Reliability: is evaluated by measuring the frequency and severity of failure, the accuracy of
output results, the mean-time-to-failure, the ability to recover from failure, and the
predictability of the program.
d. Performance: is measured by processing speed, response time, resource consumption,
throughput, and efficiency.
e. Supportability: combines the ability to extend the program extensibility, adaptability,
serviceability ➔ maintainability. In addition, testability, compatibility, configurability, etc.
2. List out the components of a Software Design Model?
The components of a software design model are :
i. Data/Class Design Model
ii. Architectural Design Model
iii. Interface Design Model
iv. Component Level Design Model
3. What are the properties that should be exhibited by a good software design according to
Mitch Kapor?
i. Firmness: A program should not have any bugs that inhibit its function.
ii. Commodity: A program should be suitable for the purposes for which it was
intended.
iii. Delight: The experience of using the program should be pleasurable one.
4. Define Abstraction ant types of abstraction?
Abstraction is the act of representing essential features without including the background details
or explanations.
A data abstraction is collection of data that describes a data object.
A procedural abstraction refers to a sequence of instructions that have a specific and limited
function. An example of a procedural abstraction would be the word open for a door.

5. Define Cohesion & Coupling (OR) What is Coupling? How it differs from cohesion
(OR)
What is Cohesion? How it differs from coupling?
Cohesion is a measure that defines the degree of intra-dependability within elements of a module.
The greater the cohesion, the better is the program design.
Coupling is a measure that defines the level of inter-dependability among modules of a program.
It tells at what level the modules interfere and interact with each other. The lower the
coupling, the better the program.
6. Define Refactoring and Aspect.
Refactoring – process of changing a software system in such a way internal structure is improved
without altering the external behavior or code design
"Refactoring is the process of changing a software system in such a way that it does not alter the
external behavior of the code [design] yet improves its internal structure.”
Aspects – a representation of a cross-cutting concern that must be accommodated as
refinement and modularization occur
7. What are the object oriented design concepts.
Object Oriented Design Concepts
i. Design classes
a. Entity classes (business classes)
b. Boundary classes (interfaces)
c. Controller classes (controller)
ii. Inheritance—all responsibilities of a super class is immediately inherited by all subclasses
iii. Messages—stimulate some behavior to occur in the receiving object
iv. Polymorphism—a characteristic that greatly reduces the effort required to extend the design
8. What are the advantages of Modularization
i. Smaller components are easier to maintain
ii. Program can be divided based on functional aspects
iii. Desired level of abstraction can be brought in the program
iv. Components with high cohesion can be re-used again
v. Concurrent execution can be made possible
vi. Desired from security aspect
9. Define Design pattern concept
a. A design pattern “conveys the essence of a proven design solution to a recurring
problem within a certain context of computing concerns.”
b.The intent of each design pattern is to provide a description that enables a designer to
determine:
i. whether the pattern is applicable to the current work,
ii. whether the pattern can be reused, and
iii. whether the pattern can serve as a guide for developing a similar, but functionally
or structurally different pattern.

10. What is Software Architecture?
The software architecture of a system is the structure or structures of the system which comprise of
i. Software components
ii. External visible properties of those components
iii. Relationships among the components
11. List out the different Architectural styles
Some of the architectural styles are:
i. Data-centered architectures
ii. Data flow architectures
iii. Call and return architectures
iv. Object-oriented architectures
v. Layered architectures
12. What is a Software Component
Definition: A software component is a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes a set of interfaces.
Functions of a component: A component communicates and collaborates with
a. Other components
b. Entities outside the boundaries of the system
Three different views of a component
c. An object-oriented view
d. A conventional view
e. A process-related view
13. What is Domain Engineering?
i. Intent is to identify, construct, catalog, and disseminate a set of software
components applicable to existing and future products in a particular application
domain.
ii. Overall goal is to establish mechanisms that allow for component sharing and
reuse during work on both new and existing systems
iii. Includes three major activities: analysis, construction, dissemination
14. Expand Design Concepts
List of design concepts are:
Abstraction Architecture
Patterns Separation of Concerns
Modularity Information Hiding
Functional Independence Refinement
Aspects Refactoring
Object Oriented Design concepts Design classes

15. Describe the role of software architecture in project development
The architecture of a system is a comprehensive framework that describes its form and
structure. Good Software developers have often adopted one or several architectural patterns as
strategies for system organization, but they use these patterns informally and have no means to
make them explicit in the resulting system.
This would include articulating the architectural vision, conceptualizing and
experimenting with alternative architectural approaches, creating models and component and
interface specification documents, and validating the architecture against requirements and
assumptions.
16. Define Software architecture with IEEE definition and its types.
The IEEE Standard defines an architectural description (AD) as a “a collection of products to
document an architecture.”
 The description itself is represented using multiple views, where each view is “a
representation of a whole system from the perspective of a related set of [stakeholder]
concerns.”
The IEEE Computer Society has proposed IEEE-Std, Recommended Practice for Architectural
Description of Software-Intensive System,
 to establish a conceptual framework and vocabulary for use during the design of software
architecture,
17. Define Software design. Write different types of software design.
Software Design is the last software engineering action within the modeling activity and
sets the stage for construction(code generation and testing). The types of software
design are:
 Data/class Design
 Architectural Design
 Interface Design
 Component Level Design
UNIT – 4
1. State Golden rules of user interface design
 Place the user in control
 Reduce the user’s memory load
 Make the interface consistent
2. Why interface analysis is critical in UI development
 Allow the user to put the current task into a meaningful context.
 Maintain consistency across a family of applications.
 If past interactive models have created user expectations, do not make changes unless there is
a compelling reason to do so.

3. What are the steps for user interface analysis and design
User model — a profile of all end users of the system
Design model — a design realization of the user model
Mental model (system perception) — the user’s mental image of what the interface is
Implementation model — the interface “look and feel” coupled with supporting information that
describe interface syntax and semantics.
4. Draw the architecture for user interface design process
5. What is interface analysis
Interface analysis means understanding
a. the people (end-users) who will interact with the system through the interface;
b. the tasks that end-users must perform to do their work,
c. the content that is presented as part of the interface
d. the environment in which these tasks will be conducted.
6. What are the steps required for interface design steps
Using information developed during interface analysis, define interface objects and actions
(operations).
Define events (user actions) that will cause the state of the user interface to change. Model this
behavior.
Depict each interface state as it will actually look to the end-user.
Indicate how the user interprets the state of the system from information provided through the
interface.
7. List out four command design issues
The 4 Command design issues are
1. Response time
2. Help Facilities
3. Error Handling
4. Menu and Command Labeling.

8. Design evaluation cycle for interface design
9. List the web application quality attributes
a. Usability
b. Functionality
c. Reliability
d. Efficiency
e. Maintainability
10. List various designs used in web application
user
11. What are the objectives of webapp design
technology
 Establish a consistent window into the content and functionality provided by the interface.
 Guide the user through a series of interactions with the webapp
 Organize the navigation options and content available to the user.To implement navigation
options, you can select from one of a number of interaction mechanisms:
a. Navigation Menus
b. Graphic icons
c. Graphic images
Interface
design
Aesthetic design
Content design
Navigation design
Architecture design
Component design

12. What is content architecture
 Content architecture focuses on the manner in which content objects (or composite objects
such as Web pages) are structured for presentation and navigation.
a. The term information architecture is also used to connote structures that lead to better
organization, labeling, navigation, and searching of content objects.
13. What is webapp architecture
-> WebApp architecture addresses the manner in which the application is structured to manage
user interaction, handle internal processing tasks, effect navigation, and present content.
-> Architecture design is conducted in parallel with interface design, aesthetic design and content
design.
14. Define MVC architecture
The model contains all application specific content and processing logic, including
a. all content objects
b. access to external data/information sources,
c. all processing functionality that are application specific
The view contains all interface specific functions and enables
a. the presentation of content and processing logic
b. access to external data/information sources,
c. all processing functionality required by the end-user.
The controller manages access to the model and the view and coordinates the flow of data
between them.
15. Define Navigation Semantic Unit(NSU)
NSU—“a set of information and related navigation structures that collaborate in the fulfillment of
a subset of related user requirements”.
Navigation semantic unit
 Ways of navigation (WoN)—represents the best navigation way or path for users with
certain profiles to achieve their desired goal or sub-goal.
• Navigation nodes (NN) connected by Navigation links
16. What are the designs included in object oriented hypermedia design method
a. Conceptual design
b. Navigational design
c. Abstract Interface design
d. Implementation

UNIT – 5
1. Who does the software testing and need of it.
 A strategy for software testing is developed by the project manager, software engineers, and
testing specialists.
 Testing often accounts for more project effort than any other software engineering action. If it
is conducted haphazardly, time is wasted, unnecessary effort is expended, and even worse,
errors sneak through undetected. It would therefore seem reasonable to establish
a systematic strategy for testing software.
2. Differentiate between Validation and Verification of a Software Product?
Verification refers to the set of tasks that ensure that software correctly implements a specific
function.
Validation refers to a different set of tasks that ensure that the software that has been built is
traceable to customer requirements.
Boehm states this another way:
a. Verification: "Are we building the product right?"
b. Validation: "Are we building the right product?"
3. Discuss testing strategy for small and large software testing
 A strategy for software testing must accommodate low-level tests that are necessary to
verify that a small source code segment has been correctly implemented as well as high level
tests that validate major system functions against customer requirements.
 Testing is conducted by the developer of the software and (for large projects) an independent
test group.
 To perform effective testing, you should conduct effective technical reviews. By doing this,
many errors will be eliminated before testing commences.
4. Define Software Testing? List out the advantages of Software Testing?
Software Testing: Testing is the process of exercising a program with the specific intent of
finding errors prior to delivery to the end user.
Advantages of software testing:
Software testing shows
1. errors
2. requirements conformance
3. performance
4. an indication of quality
5. Explain how Unit testing of a Software System is performed?
Definition: Unit testing is a method by which individual units of source code are tested to
determine if they are fit for use.

GOAL: The goal of unit testing is to segregate each part of the program and test that the
individual parts are working correctly.
The following are activities are performed in unit testing:
i. Module interfaces are tested for proper information flow.
ii. Local data are examined to ensure that integrity is maintained.
iii. Boundary conditions are tested.
iv. Basis (independent) path are tested.
v. All error handling paths should be tested.
6. List out the outcome of unit testing
Unit testing focuses verification effort on the smallest unit of software design—the
software component or module
7. What is Integration Testing?
Definition: Integration Testing is a type of software testing where individual units are combined
and tested as a group. Integration Testing exposes defects in the interfaces and in the interactions
between integrated components or systems.
8. Explain Smoke Testing?
Smoke testing: Smoke Testing, also known as “Build Verification Testing”, is a type of software
testing that comprises of a non-exhaustive set of tests that aim at ensuring that the most important
functions work.
Features of smoke testing:
1. Identifying the business critical functionalities that a product must satisfy.
2. Designing and executing the basic functionalities of the application.

3. Ensuring that the smoke test passes each and every build in order to proceed with the testing.
4. Smoke Tests enables uncovering obvious errors which saves time and effort of test team.
5. Smoke Tests can be manual or automated.
9. Discuss Regression box testing?
Regression testing: it is used to check for defects propagated to other modules by changes made
to existing program. Regression means retesting the unchanged parts of the application.
Test cases are re-executed in order to check whether previous functionality of application is
working fine and new changes have not
introduced any new bugs.
This test can be performed on a new build
when there is significant change in original
functionality or even a single bug fix.
10. Explain black box testing
Black Box Testing is a type of software
Testing, either functional or non-functional,
without reference to the internal structure of
the component or system.
It also known as Behavioral Testing, is a software testing method in which the internal structure/
design/ implementation of the item being tested is not known to the tester. These tests can be
functional or non-functional, though usually functional.
11. Explain White box testing
White Box Testing is Testing based on an analysis of the internal structure of the component or
system.
It is also known as Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box
Testing, Code-Based Testing or Structural Testing, it is a software testing method in which the
internal structure/ design/ implementation of the item being tested is known to the tester.

WHITE BOX TESTING ADVANTAGES
i. Testing can be commenced at an earlier stage. One need not wait for the GUI to be available.
ii. Testing is more thorough, with the possibility of covering most paths.
12. List out various system testing
a. Recovery Testing
b. Security Testing
c. Stress Testing
d. Performance Testing
e. Deployment Testing
13. What is the general Test criteria
Interface integrity – internal and external module interfaces are tested as each module or cluster is
added to the software
Functional validity – test to uncover functional defects in the software
Information content – test for errors in local or global data structures
Performance – verify specified performance bounds are tested
14. Explain Acceptance testing
Making sure the software works correctly for intended user in his or her normal work
environment.
There are two types of acceptance testing:
a. Alpha test
b. Beta test
Alpha test – version of the complete software is tested by customer under the supervision of the
developer at the developer’s site.
Beta test – version of the complete software is tested by customer at his or her own site without
the developer being present.
15. Explain Debugging Strategies
Debugging is the process of finding and resolving of defects that prevent correct operation of
computer software
Debugging (removal of a defect) occurs as a consequence of successful testing.
Common approaches (may be partially automated with debugging tools):
a. Brute force – memory dumps and run-time traces are examined for clues to error causes
b. Backtracking – source code is examined by looking backwards from symptom to
potential causes of errors
c. Cause elimination – uses binary partitioning to reduce the number of locations potential
where errors can exist)

G.PULLAIAH COLLEGE OF ENGINEERING AND TECHNOLOGY, Kurnool
Department of Computer Science and Engineering
Software Engineering
BITS
UNIT I
1. Software is it is not manufactured in the classical sense(developed or engineered)
2. Although the industry is moving toward component-based construction, most software
continues to be ( custom built.)
3. Layers of software are quality focus, process, methods and (tools)
4. A generic process framework for software engineering encompasses five activities:
Communication, planning, Modeling, Construction, (Deployment)
5. The essence of software engineering practice are Understand the problem (communication and
analysis), Plan a solution (modeling and software design), and Examine the result
for accuracy. (Carry out the plan (code generation),)
6. Software myths are Practitioners Myth, Managerial Meths(Customer Myth)
7. CMMI stands for ( Capability Maturity Model Integration)
8. The waterfall model, sometimes called the (classic life cycle)
9. Variation in the representation of the waterfall model is called the (V-model.)
10. The incremental model combines elements of linear and parallel process flows
11. Spiral model is also called as model (Barry Boehm model)
12. AOSD stands for (Aspect Oriented Software Development)
13. PSP stands from (Personal Software Process)
14. is a quality management technique that translates the needs of the customer
into technical requirements for software.( Quality function deployment (QFD))
15. System software—a collection of programs written to service other programs.
16. Application software—stand-alone programs that solve a specific business need.
17. Embedded software—resides within a product or system and is used to implement and control
features and functions for the end user and for the system itself.
18. Artificial intelligence software—makes use of nonnumerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis.
19. older programs—often referred to as legacy software
20. A process framework establishes the foundation for a complete software engineering process
21. umbrella activities that are applicable across the entire software process
22. Generic framework activities—communication, planning, modeling, construction, and
deployment
23. KISS (Keep It Simple, Stupid)
24. RAD – Rappid Application Development
25. The waterfall model, sometimes called the classic life cycle
26. A variation in the representation of the waterfall model is called the V-model.
27. The Spiral Model proposed by Barry Boehm
28. The concurrent development model, sometimes called concurrent engineering,
29. Commercial off-the-shelf (COTS)
30. The formal methods model encompasses a set of activities that leads to formal mathematical
specification of computer software
31. UML—a unified modeling language

32. Personal Software Process (PSP)
33. Team Software Process (TSP)
34. Agile software engineering combines a philosophy and a set of development guidelines.
35. Industrial Extreme Programming (IXP)
36. Dynamic Systems Development Method (DSDM)
37. Feature Driven Development (FDD)
UNIT II
1. The work products produced as a consequence of requirements engineering are assessed for
quality during a validation step.
2. Quality function deployment (QFD) is a quality management technique that translates the needs
of the customer into technical requirements for software.
3. Quality function deployment (QFD) is a quality management technique that translates the needs
of the customer into technical requirements for software.
4. Each usage scenario implies a set of objects that are manipulated as an actor interacts with the
system
5. Data models depict the information domain for the problem
6. Class-oriented models represents object-oriented classes (attributes and operations) and the
manner in which classes collaborate to achieve system requirements
7. Flow-oriented models represents the functional elements of the system and how they
transform data as it moves through the system
8. Behavioral models depict how the software behaves as a consequence of external “events”
9. Examples for Scenario-based models are use cases, user stories
10. Examples for Flow models are DFDs data models
11. Example for Behavioral models are state diagrams, sequence diagrams
12. A UML activity diagram represents the actions and decisions that occur as some function is
performed.
13. A UML swim lane diagram represents the flow of actions and decisions and indicates which
actors perform each.
14. Attributes describe a class
15. Operations define the behavior of an object.
16. Class-responsibility-collaborator (CRC)
17. An association defines a relationship between classes. Multiplicity defines how many of one
class are related to how many of another class.
18. A package is used to assemble a collection of related classes.
UNIT III
1. The requirements model, manifested by scenario-based, class-based, flow-oriented, and
behavioral elements,
2. The architectural design defines the relationship between major structural elements of the
software,
3. The interface design describes how the software communicates with systems that interoperate
with it, and with humans who use it.
4. The component-level design transforms structural elements of the software architecture into a
procedural description of software components.

5. The design should provide a complete picture of the software, addressing the data, functional,
and behavioral domains from an implementation perspective.
6. FURPS—functionality, usability, reliability, performance, and supportability
7. A procedural abstraction refers to a sequence of instructions that have a specific and limited
function.
8. A data abstraction is a named collection of data that describes a data object
9. Cohesion is an indication of the relative functional strength of a module.
10. Coupling is an indication of the relative interdependence among modules.
11. Refactoring is the process of changing a software system in such a way that it does not alter the
external behavior of the code [design] yet improves its internal structure.
12. Software architecture must model the structure of a system
13. and the manner in which data and procedural components collaborate with one another.
14. An architectural style is a transformation that is imposed on the design of an entire system.
15. An archetype is an abstraction (similar to a class) that represents one element of system
behavior.
16. ACD stands for architectural context diagram
17. Sharing dependencies represent dependence relationships among consumers who use the same
resource
18. Flow dependencies represent dependence relationships between producers and consumers of
resources
19. Constrained dependencies represent constraints on the relative flow of control among a set of
activities.
20. Component is “a modular, deployable, and replaceable part of a system that encapsulates
implementation and exposes a set of interfaces.”
21. ISP stands for Interface Segregation Principle.
22. Interface is the equivalent of an abstract class that provides a controlled connection between
design classes.
23. Example for Tabular Design Notation is Decision tables
UNIT IV
1. User interface design creates an effective communication medium between a human and a
computer
2. Knowledgeable, intermittent users. Reasonable semantic knowledge of the application but
relatively low recall of syntactic information.
3. Novices. No syntactic knowledge of the system and little semantic knowledge of the application
or computer usage in general.
4. The analysis and design process for user interfaces is iterative and can be represented using a
spiral model
5. Nouns (objects) and verbs (actions) are isolated to create a list of objects and actions.
6. System response time is measured from the point at which the user performs some control
action until the software responds with desired output or action.
7. Consistency. The use of navigation controls, menus, icons, and aesthetics (e.g., color, shape,
layout) should be consistent throughout the WebApp
8. Fitt’s law. “The time to acquire a target is a function of the distance to and size of the target”
9. The web design should be moderation and simple.
10. Base for web app design pyramid is Component design
11. Apex of web app design pyramid is interface design
12. Aesthetic design, also called graphic design

13. Architecture design is conducted in parallel with interface design
14. The architectural structures can be combined to form composite structures
15. Hierarchical structures are undoubtedly the most common WebApp architecture.
16. MVC stands for Model-View-Controller architecture
17. OOHDM stands for OBJECT-ORIENTED HYPERMEDIA DESIGN METHOD
18. ADV stands for abstract data view
19. NSU stands for navigation semantic units
20. An interface that uses an interaction metaphor is easier to learn and easier to use
UNIT V
1. Software is tested to uncover errors that were made inadvertently as it was designed and
constructed.
2. A Test Specification document is the work product of software testing
3. To perform effective testing, you should conduct effective technical reviews
4. Testing and debugging are different activities
5. Verification: “Are we building the product right?”
6. Validation: “Are we building the right product?”
7. ITG stands for independent test group
8. Software testing strategy may be viewed as Spiral model
9. Initially, tests focus on each component individually, ensuring that it functions properly as a unit.
Hence, the test is named as unit testing.
10. System testing is the last high-order testing
11. Driver and/or stub software must often be developed for each unit test.
12. Integration testing is a systematic technique for constructing the software architecture while at
the same time conducting tests to uncover errors associated with interfacing.
13. Regression testing may be conducted to ensure that new errors have not been introduced.
14. Smoke testing is an integration testing approach that is commonly used when product software
is developed.
15. Functional validity. Tests designed to uncover functional errors are conducted.
16. Cluster testing is one step in the integration testing of OO software.
17. The alpha test is conducted at the developer’s site by a representative group of end users.
18. The beta test is conducted at one or more end-user sites.
19. A variation on beta testing, called customer acceptance testing,
20. Many computer-based systems must recover from faults and resume processing with little or no
downtime.
21. Security testing attempts to verify that protection mechanisms built into a system will, in fact,
protect it from improper penetration.
22. Stress testing executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume
23. A variation of stress testing is a technique called sensitivity testing.
24. Performance testing is designed to test the run-time performance of software within the
context of an integrated system.
25. Deployment testing, sometimes called configuration testing
26. Debugging is not testing but often occurs as a consequence of testing

Code: 15A05401
B.Tech II Year II Semester (R15) Regular Examinations May/June 20XX
SOFTWARE ENGINEERING
(Computer Science and Engineering)
Time: 3 hours Max Marks: 70
1) PART – I (2M X 10=20M)
a) What are the layers of software engineering?
b) Define the roles in scrum.
c) State Characteristics of SRS document.
d) Identify goals of elicitation phase.
e) List out the components of a Software Design Model?
f) What is Software Architecture?
g) What are the steps for user interface analysis and design
h) List out four command design issues
i) Explain how Unit testing of a Software System is performed?
j) Explain Smoke Testing?
PART-II (10M X 5=50M)
2) a. Present various applications of software
b. Discuss the architecture of layered technology
OR
3) a. Prescriptive Process Models and Specialized Process Models
b. Explain activities of Generic process frame work
4) a. Present various Elements of the Requirements Model
b. Patterns for Requirements Modeling
OR
5) a. Requirements Modeling Strategies
b. Describe various stages involved in Requirements Engineering
6) a. Illustrate the Design Processing involved in software project
b. Brief the Component Level Design for WebApps
OR
7) a. Project the Architecture Styles and their benefits in development of an application
b. Present the concepts involved in designing Class-Based Components
R 15

8) a. The Golden Rules of User Interface Design
b. Object-Oriented Hypermedia Design Method
OR
9) a. User Interface Analysis and Design process
b. What are the Goals of Interface design
10) a. Discuss the Test Strategies of Conventional Software
b. Object-Oriented Testing Strategies in Testing
OR
11) a. Importance of Validation Testing
b. Explain the Basic Path testing with a suitable example

G.PULLAIAH COLLEGE OF ENGINEERING AND TECHNOLOGY: KURNOOL
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Subject : SOFTWARE ENGINEERING Code : 15A05401
B.Tech. II Year-II Semester (R15)
UNIT - 1
LONG ANSWER QUESTIONS
1. Explain the unique nature of web applications?
2. Define software engineering and explain the layers of software engineering?
3. Define a software process and explain the generic software process framework?
4. What are the Umbrella activities of a software process?
5. Explain the essence of software engineering practice?
6. What is a software myth and explain various types of myths?
7. Which process model leads to software reuse? Justify
8. For the development of banking software which process model will be most suitable?
Explain suggested model with processes associated with it.
9. For the development of online web based hotel booking software. Which software
process model will be suitable? Discuss suggested model with related phases associated
with it.
10. For the development of water level management system for skyscrapers. Suggest the
suitable software engineering process model. Discuss this model with its phases and
processes.
11. Explain the following software process models?
i. Waterfall model
ii. V model
iii. Incremental model
iv. Evolutionary models: prototyping model, spiral model, concurrent model
v. Other models
a. Unified process approach
b. Personal software process
c. Team software process
12. List agility principles for those who want to achieve agility
13. Explain other Agile Process Models in briefly?
14. Explain Extreme Programming Process Model?

UNIT - 2
Long Answer Questions
1. List out the seven distinct tasks of requirements engineering?
2. Explain the elements of building requirements model?
3. Develop Software Requirement Specification with requirement understanding for online
result analysis system for college.
4. Develop UML model for digital Library System with Structural and behavioral modeling
diagrams.
5. Explain the process of Eliciting requirements of a project
6. Describe the process of Scenario based modeling.
7. State the challenges involved in software requirements of a project.
8. Explain data modeling concepts with an example.
9. What is use case diagram? Draw a use case diagram for an ATM system?
10. Explain activity diagrams? Draw an activity diagram for an ATM system?
11. Explain swim lane diagrams? Draw a swim lane diagram for an ATM system?
12. What is class diagram? Draw class diagram for an ATM system?
13. What is sequence diagram? Draw a sequence diagram for library management system?
14. Illustrate state chart diagrams? Draw a state chart diagram for library management
system pin verification?
15. Illustrate data flow diagrams with the help of examples?
16. What is ER diagram? Explain with the help of examples?
17. What is SRS? How will you develop requirements model to finalize specifications for
college admission system?
18. Develop UML model for development of portal for online store with various UML
modeling diagrams.
UNIT – 3
1. Map the components of Analysis model with the respective components of Software
design Model.
2. Explain the software design process in detail
3. Explain each of the following with respect to “software design”?
a)Abstraction b) Architecture c) Patterns d) Separation of concerns
e)Modularity f) Hiding g) Functional independence h) Refinement
i)Aspects j) Refactoring k) OO design concepts l) Design Classes
4. What is software architecture? Expand the role of software architectural design.
5. What are the different architectures required in architectural styles.
6. Explain the steps required for architectural mapping using data flow.
7. Explain object oriented view and traditional view in a component level design.
8. Design a class based component with an example.

9. What are the steps required for conducting component level design.
10. Design software architecture for ERP related to student Management system with
proper styles.
11. Create class based component design with architecture modeling of UML for Web based
movie ticket management system for multiplexes.
12. What is software architectural design? What are its building blocks? Develop software
architecture for bus reservation system with proper styles.
13. Design class based component design with architecture modeling of UML for typical
search engines used to search information over internet.
UNIT – 4
1. State and explain Golden rules of User Interface
2. Write a short notes on User Interface Analysis and design.
3. Explain user interface analysis with example
4. Write a short notes on user interface design steps
5. What are the steps required for interface design workflows for webapps.
6. Write a short notes on design evaluation.
7. What are the major attributes of quality for WebApps.
8. Write a short notes on WebApp interface design And Aesthetic design.
9. What are the types of structures used in content architecture.
10. Write a short notes on MVC architecture.
11. Develop user interface design for billing system for online shopping mall such as
Amazon. Apply user interface analysis and design steps properly.
UNIT – 5
1. What are the steps required for strategic approach in Testing
2. What is the objective of unit testing? Explain
3. Explain integration testing in detail?
4. Explain strategic issues in Testing?
5. Write a short notes on validation Testing?
6. Explain System testing in detail
7. What are the characteristics that lead to testable software?
8. Explain basis path testing in detail with an example?
9. Differentiate Condition testing and Loop testing?
10. Explain Black box testing in detail?
11. Explain testing in OOA and OOD models.
12. Explain object oriented Testing method in detail
13. Write a short notes on Inter class test design

G.PULLAIAH COLLEGE OF ENGINEERING AND TECHNOLOGY, Kurnool
Department of Computer Science and Engineering
Software Engineering
TOPICS TO REMEMBER
UNIT – 1
SOFTWARE AND SOFTWARE ENGINEERING
1.1 THE NATURE OF SOFTWARE
1.1.1 Defining Software
1. Software is developed or engineered
2. Software doesn’t “wear out.”:
3. Although the industry is moving toward component-based construction,
software continues to be custom built:
1.1.2 Software Application Domains
System software
Application softwareEngineering/scientific software
Embedded software
Product-line softwareWeb applications
Artificial intelligence software
New Challenges
Open-world computing
Net sourcing
Open source
1.1.3 Legacy Software
1.2 THE UNIQUE NATURE OF WEBAPPS
Network intensiveness
Concurrency. Unpredictable load
Performance. Availability
Data driven. Content sensitive
Continuous evolution
Immediacy
Security
Aesthetics
1.3 SOFTWARE ENGINEERING
Layered Technology
1.4 The software Process
Communication. Planning.
ModelingConstruction..
Deployment.
Software project tracking and control
Risk management
Software quality assuranceTechnical reviews
Measurement
Software configuration management
Reusability management.
Work product preparation and production

1.5 Software Engineering Practice
1.5.1 Introduction
Understand the problem.
Plan the solution
Plan the solution.
Examine the result.
1.5.2 General Principles
The First Principle: The Reason It All Exists
The Second Principle: KISS (Keep It Simple, Stupid!)
The Third Principle: Maintain the Vision
The Fourth Principle: What You Produce, Others Will Consume
The Fifth Principle: Be Open to the Future
The Sixth Principle: Plan Ahead for Reuse
The Seventh principle: Think!
1.6 Software myths
Management myths.
Customer myths
Practitioner’s myths.
1.7 PROCESS MODELS
1.7 A GENERIC PROCESS MODEL:
1.7.1 Defining a Framework Activity
1.7.2 Identifying a Task Set
1.7.3 Process Patterns
1.8 PROCESS ASSESSMENT AND IMPROVEMENT
Standard CMMI Assessment Method for Process Improvement (SCAMPI)
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
SPICE (ISO/IEC15504
ISO 9001:2000 for Software
1.9 PRESCRIPTIVE PROCESS MODELS
1.9.1 The Waterfall Model
1.9.2 Incremental Process Models
1.9.3 Evolutionary Process Models
Prototyping
The Spiral Model
1.9.4 Concurrent Models
1.10 SPECIALIZED PROCESS MODELS
1.10.1 Component-Based Development
1.10.2 The Formal Methods Model
1.10.3 Aspect-Oriented Software Development
1.11 THE UNIFIED PROCESS
1.11.1 Introduction
1.11.2 Phases of the Unified Process
1.12 PERSONAL AND TEAM PROCESS MODELS
1.12.1 Introduction
1.12.2 Personal Software Process (PSP)
Planning.
High-level design
High-level design review
Development, Postmortem
1.12.3 Team Software Process (TSP)

1.13 PROCESS TECHNOLOGY
1.14 PRODUCT AND PROCESS
People
Process
Product:
AGILITY
1.15 WHAT IS AGILITY?
1.16 AGILITY AND THE COST OF CHANGE
1.17 WHAT IS AN AGILE PROCESS?
1.17.1 Agility Principles
1.17.2 The Politics of Agile Development
1.17.3 Human Factors
Competence
Common focus
Collaboration:
Decision-making ability
Fuzzy problem-solving ability
Fuzzy problem-solving ability
Self-organization
1.18 EXTREME PROGRAMMING (XP)
1.18.1 XP Values
1.18.2 XP Process
1.18.3 Industrial XP
Readiness assessment
Project community
Project chartering
Test-driven management
Retrospectives
1.18.4 The XP Debate
• Requirements volatility.
• Conflicting customer needs.
• Requirements are expressed informally.
• Lack of formal design.
1.19 OTHER AGILE PROCESS MODELS
1.19.1 Adaptive Software Development (ASD)
1.19.2 Scrum
1.19.3 Dynamic Systems Development Method (DSDM)
1.19.4 Crystal
1.19.5 Feature Driven Development (FDD):
1.19.6 Lean Software Development (LSD
1.19.7 Agile Modeling (AM):
1.19.8 Agile Unified Process (AUP)
• Modeling
• Implementation
• Testing
• Deployment
• Configuration and project management
• Environment management

UNIT – 2
2.0 UNDERSTANDING REQUIREMENTS
2.1 REQUIREMENTS ENGINEERING
a) Inception.
b)Elicitation.
c)Elaboration.
d)Negotiation.
e)Specification.
2.2 ESTABLISHING THE GROUNDWORK
2.2.1 Identifying Stakeholders
2.2.2 Recognizing Multiple Viewpoints
2.2.3 Working toward Collaboration
2.2.4 Asking the First Questions
2.3 ELICITING REQUIREMENTS
2.3.1 Collaborative Requirements Gathering:
2.3.2 Quality Function Deployment:
Normal requirements.
Expected requirements.
Exciting requirements
2.3.3 Usage Scenarios:
2.3.4 Elicitation Work Products:
2.4 DEVELOPING USE CASES
2.5 BUILDING THE REQUIREMENTS MODEL
2.5.1 Elements of the Requirements Model
Scenario-based elements.
Class-based elements
Behavioral elements.
Flow-oriented elements.
2.5.2 Analysis Patterns
2.6 NEGOTIATING REQUIREMENTS
2.7 VALIDATING REQUIREMENTS
2.8 Requirements Modeling (Scenarios, Information and Analysis Classes)
2.8 REQUIREMENTS ANALYSIS
2.8.1.1 Overall Objectives and Philosophy:
2.8.1.2 Analysis Rules of Thumb
2.8.1.3 Domain Analysis
2.8.1.4 Requirements Modeling Approaches:
2.8.2 SCENARIO-BASED MODELING
2.8.2.1 Creating a Preliminary Use Case
2.8.2.2 Refining a Preliminary Use Case
2.8.2.3 Writing a Formal Use Case
2.8.3 UML MODELS THAT SUPPLEMENT THE USE CASE
2.8.3.1 Developing an Activity Diagram:
2.8.3.2 Swimlane Diagrams
2.8.4 DATA MODELING CONCEPTS:
2.8.4.1 Data Objects
2.8.4.2 Data Attributes
2.8.4.3 Relationships

2.8.5 CLASS-BASED MODELING
2.8.5.1 Identifying Analysis Classes
2.8.5.2 Specifying Attributes
2.8.5.3 Defining Operations
2.8.5.4 Class-Responsibility-Collaborator (CRC) Modeling
2.8.5.5 Associations and Dependencies
2.8.5.6 Analysis Packages
2.9 Requirements Modeling (Flow, Behavior, Patterns and WEBAPPS)
2.9.2 FLOW-ORIENTED MODELING
2.9.2.1 Creating a Data Flow Model
2.9.2.2 Creating a Control Flow Model
2.9.2.3 The Control Specification
2.9.2.4 The Process Specification:
2.9.3 CREATING A BEHAVIORAL MODEL
2.9.3.1 Identifying Events with the Use Case:
2.9.3.2 State Representations:
Sequence diagrams.
2.10 PATTERNS FOR REQUIREMENTS MODELING
2.10.4.1 Discovering Analysis Patterns:
2.10.2 A Requirements Pattern Example
2.11 REQUIREMENTS MODELING FOR WEBAPPS
2.11.1 How Much Analysis Is Enough?
2.11.2 Requirements Modeling Input:
2.11.3 Requirements Modeling Output:
2.11.4 Content Model for WebApps:
2.11.5 Interaction Model for WebApps:
2.11.6 Functional Model for WebApps
2.11.7 Configuration Models for WebApps
2.11.8 Navigation Modeling
3.0 DESIGN CONCEPTS
UNIT – 3
3.1 DESIGN WITHIN THE CONTEXT OF SOFTWARE ENGINEERING
3.2 THE DESIGN PROCESS
3.2.1 Software Quality Guidelines and Attributes:
3.2.2 The Evolution of Software Design
3.3 DESIGN CONCEPTS
3.3.1 Abstraction
3.3.2 Architecture
3.3.3 Patterns
3.3.4 Separation of Concerns
3.3.5 Modularity
3.3.6 Information Hiding
3.3.7 Functional Independence
3.3.8 Refinement
3.3.9 Aspects
3.3.10 Refactoring
3.3.11 Object-Oriented Design Concepts:

3.3.12 Design Classes

3.4 THE DESIGN MODEL
3.4.1 Data Design Elements
3.4.2 Architectural Design Elements
3.4.3 Interface Design Elements
3.4.4 Component-Level Design Elements
3.4.5 Deployment-Level Design Elements
3.5 Architectural Design
3.5 SOFTWARE ARCHITECTURE
3.5.1 What Is Architecture?
3.5.1.2 Why Is Architecture Important?
3.5.1.3 Architectural Descriptions
3.5.1.4 Architectural Decisions
3.5.2 Architectural Genres
3.6 ARCHITECTURAL STYLES
3.6.1 A Brief Taxonomy of Architectural Styles
3.6.2 Architectural Patterns
3.6.3 Organization and Refinement
3.7 ARCHITECTURAL DESIGN
3.7.1 Representing the System in Context
3.7.2 Defining Archetypes
3.7.3 Refining the Architecture into Components
3.7.4 Describing Instantiations of the System
3.8 ASSESSING ALTERNATIVE ARCHITECTURAL DESIGNS
3.8.1 An Architecture Trade-Off Analysis Method
3.8.2 Architectural Complexity
3.8.3 Architectural Description Languages:
3.9 ARCHITECTURAL MAPPING USING DATA FLOW
3.9.1 Transform Mapping
3.9.2 Refining the Architectural Design
3.10.1 What Is A Component?
3.10.2 The Traditional View
3.10.3 A Process-Related View
3.11 DESIGNING CLASS-BASED COMPONENTS
3.11.1 Basic Design Principles
3.11.2 Component-Level Design Guidelines
3.11.3 Cohesion
3.11.4 Coupling
3.11.3 Conducting Component-Level Design
3.12 COMPONENT-LEVEL DESIGN FOR WEBAPPS
.3.12.1 Content Design at the Component Level
3.12.2 Functional Design at the Component Level
3.13 DESIGNING TRADITIONAL COMPONENTS
3.13.1 Graphical Design Notation
3.13.2 Tabular Design Notation
3.13.3 Program Design Language
3.14 COMPONENT-BASED DEVELOPMENT
3.14.1 Domain Engineering
3.14.2 Component Qualification, Adaptation, and Composition
3.14.3 Analysis and Design for Reuse

3.14.4 Classifying and Retrieving Components
UNIT – 4
4.0 User Interface Design
4.1 The Golden Rules
4.1.1 Place The User In Control
4.1.2 Reduce The User’s Memory Load
4.1.3 Make The Interface Consistent
4.2 User Interface Analysis And Design
4.2.1 Interface Analysis And Design Models
4.2.2 The Process
4.3 Interface Analysis
4.3.1 User Analysis
4.3.2 Task Analysis And Modeling
4.3.3 Analysis Of Display Content
4.3.4 Analysis Of The Work Environment
4.4 Interface Design Steps
4.4.1 Applying Interface Design Steps
4.4.2 User Interface Design Patterns
4.4.3 Design Issues
4.5 Webapp Interface Design
4.5.1 Interface Design Principles And Guidelines
4.5.2 Interface Design Workflow For Webapps
4.6 Design Evaluation
4.7 Webapp Design
4.7.1 Web App Design Quality:
4.7.2 Design Goals:
4.7.3 A Design Pyramid For Webapps:
4.7.4 Webapp Interface Design
4.7.5.1 Layout Issues
4.7.5.2 Graphic Design Issues
4.8 Content Design
4,8.1 Content Objects
4.8.2 Content Design Issues
4.9 Architecture Design
4.9.1 Content Architecture
4.9.2 Webapp Architecture
4.10 Navigation Design
4.10.1 Navigation Semantics
4.10.2 Navigation Syntax
4.12 Object-Oriented Hypermedia Design Method (OOHDM)
4.12.1 Conceptual Design For OOHDM:
4.12.2 Navigational Design For OOHDM:
4.12.3 Abstract Interface Design And Implementation:

5.0 Software Testing
UNIT – 5
5.1 A Strategic Approach To Software Testing
5.1.1 Verification and Validation
5.1.2 Organizing for Software Testing
5.1.3 Software Testing Strategy—The Big Picture
5.1.4 Criteria for Completion of Testing
5.2 Strategic Issues
5.3 Test Strategies For Conventional Software
5.3.1 Unit Testing
5.3.2 Integration Testing
Top-down integration
Bottom-up integration
Regression testing
Smoke testing
Strategic options
Integration test work products
5.4 Test Strategies For Object-Oriented Software
5.4.1 Unit Testing in the OO Context
5.4.2 Integration Testing in the OO Context
5.5 Test Strategies For Webapps
5.6 Validation Testing
5.6.1 Validation-Test Criteria
5.6.2 Configuration Review
5.6.3 Alpha and Beta Testing
5.7 SYSTEM TESTING
5.7.1 Recovery Testing
5.7.2 Security Testing
5.7.3 Stress Testing
5.7.4 Performance Testing
5.7.5 Deployment Testing
5.8 THE ART OF DEBUGGING
5.8.1 The Debugging Process
5.8.2 Psychological Considerations
5.8.3 Debugging Strategies - Automated debugging
5.8.4 Correcting the Error
5.9 Testing Conventional Applications
5.9.1 Software Testing Fundamentals
5.9.2 Internal And External Views Of Testing
5.9.3 White-Box Testing
5.9.4 Basis Path Testing
5.9.4.1 Flow Graph Notation
5.9.4.2 Independent Program Paths
5.9.4.3 Deriving Test Cases
1. Using the design as foundation, draw a corresponding flow graph
2. Determine the cyclomatic complexity of the resultant flow graph.
3. Determine a basis set of linearly independent paths
4. Prepare test cases that will force execution of each path in the basis set

5.9.4.4 Graph Matrices

5.9.5 CONTROL STRUCTURE TESTING
5.9.5.1 Condition Testing
5.9.5.2 Data Flow Testing
5.9.5.3 Loop Testing:
Nested loops
Concatenated loops
Unstructured loops
5.9.6 BLACK-BOX TESTING
5.9.6.1 Graph-Based Testing Methods
Transaction flow modeling
Finite state modeling
Data flow modeling
Timing modeling
5.9.6.2 Equivalence Partitioning
5.9.6.3 Boundary Value Analysis
5.9.6.4 Orthogonal Array Testing
Detect and isolate all single mode faults
Detect all double mode faults
Multimode faults
5.9.7 MODEL-BASED TESTING
1. Analyze an existing behavioral model for the software or create one
2. Traverse the behavioral model and specify the inputs that will force the software to make the
transition from state to state.
3. Review the behavioral model and note the expected outputs as the software makes the
transition from state to state
4. Execute the test cases
5. Compare actual and expected results and take corrective action as required
5.10 TESTING FOR SPECIALIZED ENVIRONMENTS, ARCHITECTURES, APPLICATIONS
5.10.1 Testing GUIs
5.10.2 Testing of Client-Server Architectures
• Application function tests
• Server tests
• Database tests
• Transaction tests
• Network communication tests
5.10.3 Testing Documentation and Help Facilities
5.10.4 Testing for Real-Time Systems
• Task testing
• Behavioral testing .
• Intertask testing
• System testing
5.11 PATTERNS FOR SOFTWARE TESTING
5.12 TESTING OBJECT ORIENTED APPLICATIONS
5.12.1.BROADENING THE VIEW OF TESTING
5.12.2 TESTING OOA AND OOD MODELS
5.12.2.1 Correctness of OOA and OOD Models
5.12.2.2 Consistency of Object-Oriented Models
1. Revisit the CRC model and the object-relationship model
2. Inspect the description of each CRC index card to determine if a delegated responsibility is part of the
collaborator’s definition

3. Invert the connection to ensure that each collaborator that is asked for service is receiving requests
from a reasonable source
4. Using the inverted connections examined in step 3, determine whether other classes might be required
or whether responsibilities are properly grouped among the classes.
5. Determine whether widely requested responsibilities might be combined into a single responsibility
5.12.3 OBJECT-ORIENTED TESTING STRATEGIES
5.12.3.1 Unit Testing in the OO Context
5.12.3.2 Integration Testing in the OO Context
5.12.3.3 Validation Testing in an OO Context
5.12.4 OBJECT-ORIENTED TESTING METHODS
5.12.4.1 The Test-Case Design Implications of OO
5.12.4.2 Applicability of Conventional Test-Case Design Methods
5.12.4.3 Fault-Based Testing
5.12.4.4 Test Cases and the Class Hierarchy
5.12.4.5 Scenario-Based Test Design
5.12.4.6 Testing Surface Structure and Deep
5.12.5 TESTING METHODS APPLICABLE AT THE CLASS LEVEL
5.12.5.1 Random Testing for OO Classes
5.12.5.2 Partition Testing at the Class Level
5.13 INTERCLASS TEST-CASE DESIGN
5.13.1 Multiple Class Testing
5.13.2 Tests Derived from Behavior

SE-TEXT-BOOK_Material.doc

More Related Content

Similar to SE-TEXT-BOOK_Material.doc (20)

More from DrPreethiD1 (18)

Recently uploaded (20)

SE-TEXT-BOOK_Material.doc