lOMoARcPSD|32859433

SE Digital Notes

CSE (Software Engineering) (Jawaharlal Nehru Technological University, Hyderabad)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Arsh Khan ([email protected])
 lOMoARcPSD|32859433

LECTURE NOTES ON
SOFTWARE ENGINEERING
(2005PC05)

II B.Tech. II Semester

Prepared under the Supervision of

Dr. C.V.P.R.PRASAD
Professor & Head,
Department of CSE

By
Dr.N.Kirubakaran Mrs. Preethi Kulkarni
Professor, Dept of CSE Assistant Professor,Dept of CSE

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

MALLAREDDY ENGINEERING COLLEGE FOR WOMEN
(Autonomous Institution-UGC, Govt. of India)
Permanently Affiliated to JNTUH, Approved by AICTE, ISO 9001:2015 CertifiedInstitution
Accredited by NBA and MAC with ‘A’ Grade UGC, Govt. of India
NIRF Indian Ranking-2018, Accepted by MHRD, Govt. of India,
CSR-6th Rank AAAA+ Rated by Digital Learning, AAA+ Rated by Careers 360 Magazine,
National Ranking – Top 100 National Ranking by Times News Paper
National Ranking – Top 100 Rank band by Outlook Maisammaguda,
Dhulapally, Secunderabad, Kompally-500100

2021 – 2022

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

SYLLABUS
UNIT- I
Introduction to Software Engineering: The evolving role of software, Changing Nature of
Software, legacy software, Software myths.
A Generic view of process: Software engineering- A layered technology, a process
framework, The Capability Maturity Model Integration (CMMI), Process patterns, process
assessment, personal and team process models.
Process models: The waterfall model, Incremental process models, Evolutionary process
models, specialized process models, The Unified process.
Understand the Agile View of Process: Agility and Agile Process models of Agile
Development and Tools.

UNIT- II
Software Requirements: Functional and non-functional requirements, User requirements,
System requirements, Interface specification, the software requirements document.
Requirements engineering process: Feasibility studies, Requirements elicitation and
analysis, Requirements validation, Requirements management.
System models: Context Models, Behavioral models, Data models, Object models, structured
methods.
UML Diagrams.

UNIT- III
Design Engineering: Design process and Design quality, Design concepts, the design model,
pattern based software design.
Creating an architectural design: software architecture, Data design, Architectural styles
and patterns, Architectural Design, assessing alternative architectural designs, mapping data
flow into software architecture.
Modeling component-level design: Designing class-based components, conducting
component-level design, object constraint language, designing conventional components.
Performing User interface design: Golden rules, User interface analysis, and design,
interface analysis, interface design steps.

UNIT- IV
Testing Strategies: A strategic approach to software testing, test strategies for conventional
software, Black- Box and White-Box testing, Validation testing, System testing, the art of
Debugging.
Product metrics: Software Quality, Frame work for Product metrics, Metrics for Analysis
Model, Metrics for Design Model, Metrics for source code, Metrics for testing, Metrics for
maintenance.
Metrics for Process and Products: Software Measurement, Metrics for software quality.
UNIT- V
Risk management: Reactive vs Proactive Risk strategies, software risks, Risk identification,

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Risk projection, Risk refinement, RMMM, RMMM Plan.

Quality Management: Quality concepts, Software quality assurance, Software Reviews,
Formal technical reviews, Statistical Software quality Assurance, Software reliability, The
ISO 9000 quality standards.

TEXT BOOKS:
1) Software engineering A practitioner’s Approach, Roger S Pressman, sixth edition
McGraw Hill International Edition.
2) Software Engineering, Ian Sommerville, seventh edition, Pearson education.

REFERENCE BOOKS:
1) Software Engineering, A Precise Approach, Pankaj Jalote, Wiley India, 2010.
2) Software Engineering : A Primer, Waman S Jawadekar, Tata McGraw-Hill, 2008
3) Fundamentals of Software Engineering, Rajib Mall, PHI, 2005
4) Software Engineering, Principles and Practices, Deepak Jain, Oxford University Press
5) Software Engineering1: Abstraction and modeling, Diner Bjorner, Springer International
edition, 2006.
6) Software Engineering 2: Specification of systems and languages, Diner Bjorner, Springer
International edition 2006.
7) Software Engineering Foundations, Yingxu Wang, Auerbach Publications, 2008.
8) Software Engineering Principles and Practice, Hans Van Vliet, 3 rd edition, John Wiley
&Sons Ltd.
9) Software Engineering 3: Domains, Requirements, and Software Design, D. Bjorner,
Springer International Edition.
10) Introduction to Software Engineering, R. J. Leach, CRC

COURSE OBJECTIVES
 To understanding of software process models such as waterfall and evolutionary models.
 To understanding of software requirements and SRS document.
 To understanding of different software architectural styles.
 To understanding of software testing approaches such as unit testing and integration
testing.
 To understanding on quality control and how to ensure good quality software.

COURSE OUTCOMES
CO1: Apply basic knowledge and understanding of the analysis, synthesis and design of
complex systems.
CO2: Apply software engineering principles and techniques.
CO3: Design and evaluate large-scale software systems.
CO4: Illustrate the managing time, processes and resources effectively by prioritizing
competing demands.
CO5: Develop as an effective member or leader of software engineering teams.

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

COURSE OUTCOMES MAPPING WITH PROGRAM OUTCOMES

Course PO PO PO PO PO PO PO PO PO PO1 PO1 PO1
Outcome 1 2 3 4 5 6 7 8 9 0 1 2
CO1
CO2
CO3
CO4
CO5

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

INDEX
S.NO TITLE PAGE NO
UNIT – 1
1.1 The evolving role of software 1
1.2 Changing Nature of Software, Legacy Software 3
1.3 Software Myths 5
1.4 Software engineering- A Layered Engineering 7
1.5 A Process Framework 8
1.6 The Capability Maturity Model Integration (CMMI) 11
1.7 Process Patterns 13
1.8 Process Assessment 15
1.9 Personal and Team Process Models 16
1.10 Waterfall Model 18
1.11 Incremental Process Models 19
1.12 Evolutionary Process models 22
1.13 Specialized Process models 27
1.14 The Unified Process 29
1.15 Understand the Agile View of Process : Agility 31
1.16 Agile Process models of Agile Development and Tools 33
UNIT – 2
2.1 Functional and non Functional requirements 39
2.2 User requirements 40
2.3 System Requirements 41
2.4 Interface Specifications 51
2.5 The Software requirements Documents 52
2.6 Feasibility Studies 55
2.7 Requirements elicitation and analysis 56
2.8 Requirements validation 64
2.9 Requirements Management 65
2.10 System models context Models: Behavioral Models 67
2.11 Data Models 71
2.12 Object Models 72
2.13 Structured Methods 75
2.14 UML Diagrams. 77
UNIT-3
3.1.1 Design Engineering- Design process and Design quality 103
3.1.2 Design concepts 105
3.1.3 The Design model 111
3.2.1 Creating an architectural design software architecture – Data Design 115

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

S.NO TITLE PAGE NO

3.2.2 Architectural Styles and patterns 117
3.2.3 Architectural Design 122
3.3.1 Designing class based components 122
3.3.2 Conducting component level design 123
3.3.3 Designing conventional components 124
3.3.4 Object constraint language 125
3.3.5 Performing User interface design- Golden Rules 126
3.3.6 User interface analysis, Design interface analysis 131
3.3.7 Design evaluation 138
UNIT-4
4.1. Testing strategies: A strategic approach to software testing. 140
4.2 Test strategies for conventional software 142
4.3 Validation testing 150
4.4 System testing 151
4.5 The art of Debugging 152
4.6 White Box Testing 153
4.7 Black Box Testing 161
4.8 Product Metrics: Software Quality, Frame work for Product metrics 166
4.9 Metrics for Analysis Model. 168
4.10 Metrics for Design model 171
4.11 Metrics for source code 176
4.12 Metrics for testing 177
4.13 Metrics for maintenance 177
4.14 Metrics for Process and Products: Software Measurement 177
4.15 Metrics for Software Quality 180
UNIT- 5
5.1 Risk management: Reactive vs Proactive Risk strategies 182
5.2 Software Risks 182
5.3 Risk Identification 183
5.4 Risk Projection 184
5.5 Risk Refinement 187
5.6 RMMM and RMMM Plan 189
5.7 Quality Management: Quality concepts 190
5.8 Software Quality Assurance 192
5.9 Software Reviews 194
5.10 Formal Technical Reviews 194
5.11 Statistical Software Quality Assurance 197
5.12 Software Reliability 198
5.13 The ISO 9000 quality standards. 199

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

S.NO TITLE PAGE NO

6 TUTORIAL QUESTIONS 200
7 ASSIGNMENT QUESTIONS 201
8 OBJECTIVE QUESTIONS 203
9 UNIT WISE QUESTIONS 212
10 EXTERNAL PAPERS 215
11 INTERNAL PAPERS 222
12 REFERENCES, E-LINKS, WEBSITES 224

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT- I
INTRODUCTION TO SOFTWARE ENGINEERING

Software: Software is
1) Instructions (computer programs) that provide desired features, function, and
performance, when executed
2) Data structures that enable the programs to adequately manipulate information
3) Documents that describe the operation and use of the programs.

Characteristics of Software:
1) Software is developed or engineered; it is not manufactured in the classical sense.
2) Software does not ―wear out
3) Although the industry is moving toward component-based construction, most
software continues to be custom built.

Software Engineering:
1) The 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)

EVOLVING ROLE OF SOFTWARE:

Software takes dual role. It is both a product and a vehicle for delivering a
product. As a product: It delivers the computing potential embodied by computer
Hardware or by a network of computers.

As a vehicle: It is information transformer-producing, managing, acquiring,

modifying, displaying, or transmitting information that can be as simple as single bit
or as complex as a multimedia presentation.

Software delivers the most important product of our time-information.

 It transforms personal data
 It manages business information to enhance competitiveness
 It provides a gateway to worldwide information networks
 It provides the means for acquiring information

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 1

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The role of computer software has undergone significant change over a span of little
more than 50 years
 Dramatic Improvements in hardware performance
 Vast increases in memory and storage capacity
 A wide variety of exotic input and output options
1970s and 1980s:
 Osborne characterized a ―new industrial revolution
 Toffler called the advent of microelectronics part of - the third wave of change‖
in human history
 Naisbitt predicted the transformation from an industrial society to an - information
society
 Feigenbaum and McCorduck suggested that information and knowledge would be
the focal point for power in the twenty-first century
 Stoll argued that the ―electronic community‖ created by networks and software
was the key to knowledge interchange throughout the world

1990s began:
 Toffier described a ―power shift‖ in which old power structures disintegrate as
computers and software lead to a ―democratization of knowledge
 Yourdon worried that U.S companies might lose their competitive edge in
software related business and predicted ―the decline and fall of the American
programmer
 Hammer and Champy argued that information technologies were to play a pivotal
role in the Re-engineering of the corporation‖.

Mid-1990s:
 The pervasiveness of computers and software spawned a rash of books by neo-
luddites.

Later 1990s:
 Yourdon reevaluated the prospects of the software professional and suggested the
rise and resurrection‖ of the American programmer.
 The impact of the Y2K ―time bomb‖ was at the end of 20th century

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 2

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

2000s progressed:
 Johnson discussed the power of ―emergence‖ a phenomenon that explains what
happens when interconnections among relatively simple entities result in a system
that self-organizes to form more intelligent, more adaptive behavior
 Yourdon revisited the tragic events of 9/11 to discuss the continuing impact of
global terrorism on the IT community
 Wolfram presented a treatise on a ―new kind of science‖ that posits a unifying
theory based primarily on sophisticated software simulations
 Daconta and his colleagues discussed the evolution of ―the semantic web.
 Today a huge software industry has become a dominant factor in the economies of
the industrialized world.

THE CHANGING NATURE OF SOFTWARE:

The 7 broad categories of computer software present continuing challenges for
software
 Engineers
 System software
 Application software
 Engineering/scientific software Embedded software
 Product-line software Web-applications
 Artificial intelligence software.

System software: System software is a collection of programs written to service other

programs. The systems software is characterized by
 Heavy interaction with computer hardware heavy usage by multiple users
 Concurrent operation that requires scheduling, resource sharing, and sophisticated
process management
 Complex data structures
 Multiple external interfaces
E.g. compilers, editors and file management utilities.

Application software:
 Application software consists of standalone programs that solve a specific
business need.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 3

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 It facilitates business operations or management/technical decision making.

 It is used to control business functions in real-time
E.g. Point-of-sale transaction processing, real-time manufacturing process control.

Engineering/Scientific software:
 Engineering and scientific applications range from astronomy to volcanology
 From automotive stress analysis to space shuttle orbital dynamics
 From molecular biology to automated manufacturing
E.g. computer aided design, system simulation and other interactive applications.

Embedded software:
 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.
 It can perform limited and esoteric functions or provide significant function and
control capability.
 E.g. Digital functions in automobile, dashboard displays, braking systems etc.

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 market
place or address mass consumer markets, Word processing, spreadsheets, computer
graphics, multimedia, entertainment, database management, personal and business
financial applications

Web-applications: WebApps are evolving into sophisticated computing

environments that not only provide standalone features, computing functions, and
content to the end user, but also are integrated with corporate databases and business
applications.

Artificial intelligence software: AI software makes use of nonnumerical algorithms

to solve complex problems that are not amenable to computation or straightforward
analysis. Application within this area includes robotics, expert systems, pattern
recognition, artificial neural networks, theorem proving, and game playing.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 4

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The following are the new challenges on the horizon:

 Ubiquitous computing
 Net sourcing
 Open source
 The new economy

Ubiquitous computing: The challenge for software engineers will be to develop

systems and application software that will allow small devices, personal computers
and enterprise system to communicate across vast networks.

Net sourcing: The challenge for software engineers is to architect simple and
sophisticated applications that provide benefit to targeted end-user market worldwide.

Open Source: The challenge for software engineers is to build source that is self
descriptive but more importantly to develop techniques that will enable both
customers and developers to know what changes have been made and how those
changes manifest themselves within the software.

The new economy: The challenge for software engineers is to build applications that
will facilitate mass communication and mass product distribution.

SOFTWARE MYTHS
Beliefs about software and the process used to build it- can be traced to the
earliest days of computing myths have a number of attributes that have made them
insidious.

Management myths: Manages with software responsibility, like managers in most

disciplines, are often under pressure to maintain budgets, keep schedules from
slipping, and improve quality.

Myth: We already have a book that‘s full of standards and procedures for building
software - Wont 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?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 5

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Myth: If we get behind schedule, we can add more programmers and catch up.

Reality: Software development is not a mechanistic process like manufacturing. As

new people are added, people who were working must spend time educating the new
comers, thereby reducing the amount of time spend 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 built 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: 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 with 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 recipe for disaster.

Myth: Project 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 and change can cause upheaval that requires
additional resources and major design modification.

Practitioner’s myths: Myths that are still believed by software practitioners: during
the early days of software, programming was viewed as an art from old ways and
attitudes die hard.

Myth: Once we write the program and get it to work, our jobs are 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: The only deliverable work product for a successful project is the working
program.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 6

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Reality: A working program is only one part of a software configuration that includes
many elements. Documentation provides guidance for software support.

Myth: software engineering will make us create voluminous and unnecessary

documentation and will invariably slows down.

Reality: software engineering is not about creating documents. It is about creating

quality. Better quality leads to reduced rework. And reduced rework results in faster
delivery times.

A GENERIC VIEW OF PROCESS

SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY:

Tools

Methods

Process

A quality focus

Figure 1.1
Software Engineering Layers
Software engineering is a layered technology. Any engineering approach must
rest on an organizational commitment to quality. The bedrock that supports
software engineering

The foundation for software engineering is the process layer. Software

engineering process is the glue that holds the technology layers. Process defines a
framework that must be established for effective delivery of software engineering
technology.

The software forms the basis for management control of software projects and
establishes the context in which
 Technical methods are applied,
 Work products are produced,
 Milestones are established,

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 7

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 Quality is ensured,
 And change is properly managed.

Software engineering methods rely on a set of basic principles that govern area
of the technology and include modeling activities.
Methods encompass a broad array of tasks that include
 Communication,
 Requirements analysis,
 Design modeling,
 Program construction,
 Testing and support.

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.

A PROCESS FRAMEWORK:
 Software process must be established for effective delivery of software
engineering technology.
 A process framework establishes the foundation for a complete software process
by identifying a small number of framework activities that are applicable to all
software projects, regardless of their size or complexity.
 The process framework encompasses a set of umbrella activities that are
applicable across the entire software process.
 Each framework activity is populated by a set of software engineering actions
 Each software engineering action is 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.

In brief
"A process defines who is doing what, when, and how to reach a certain goal. “

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 8

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

A Process Framework is
 Establishes the foundation for a complete software process
 Identifies a small number of framework activities
 Applies to all s/w projects, regardless of size/complexity.
 Also, set of umbrella activities
 Applicable across entire s/w process.
 Each framework activity has set of s/w engineering actions.
 Each s/w engineering action (e.g., design) has collection of related tasks (called
task sets): work tasks work products (deliverables)

Generic Process Framework: It is applicable to the vast majority of software

projects
 Communication activity
 Planning activity
 Modeling activity
 Analysis action
 Requirements gathering work task
 Elaboration work task
 Negotiation work task
 Specification work task
 Validation work task
 Design action
 Data design work task
 Architectural design work task
 Interface design work task
 Component-level design work task
 Construction activity
 Deployment activity
1. Communication: This framework activity involves heavy communication and
collaboration with the customer and encompasses requirements gathering and
other related activities
2. Planning: This activity establishes a plan for the software engineering work that
follows. It describes the technical tasks to be conducted, the risks that are likely,

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 9

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

the resources that will be required, the work products to be produced, and a work
schedule
3. Modeling: This activity encompasses the creation of models that allow the
developer and customer to better understand software requirements and the design
that will achieve those requirements. The modeling activity is composed of 2
software engineering actions- analysis and design.
 Analysis encompasses a set of work tasks.
 Design encompasses work tasks that create a design model.
4. Construction: This activity combines core generation and the testing that is
required to uncover the errors in the code
5. Deployment: The software is delivered to the customer who evaluates the
delivered product and provides feedback based on the evolution.

These 5 generic framework activities can be used during the development of

small programs, the creation of large web applications, and for the engineering of
large, complex computer-based systems.

The following are the set of Umbrella Activities.

Software project tracking and control – allows the software team to assess progress
against the project plan and take necessary action to maintain schedule.

Risk Management - assesses risks that may effect the outcome of the project or the
quality of the product.

Software Quality Assurance - defines and conducts the activities required to ensure
software quality.

Formal Technical Reviews - assesses software engineering work products in an

effort to uncover and remove errors before they are propagated to the next action or
activity.

Measurement - define and collects process, project and product measures that assist
the team in delivering software that needs customer‘s 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.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 10

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Reusability management - defines criteria for work product reuse and establishes
mechanisms to achieve reusable components.
Work Product preparation and production - encompasses the activities required to
create work products such as models, document, logs, forms and lists.
Intelligent application of any software process model must recognize that adaption is
essential for success but process models do differ fundamentally in:
 The overall flow of activities and tasks and the interdependencies among activities
and tasks.
 The degree through which work tasks are defined within each frame work activity.
 The degree through which work products are identified and required.
 The manner which quality assurance activities are applied.
 The manner in which project tracking and control activities are applied.
 The overall degree of the detailed and rigor with which the process is described.
 The degree through which the customer and other stakeholders are involved with
the project.
 The level of autonomy given to the software project team.
 The degree to which team organization and roles are prescribed.

THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI):

The CMMI represents a process meta-model in two different ways:
 As a continuous model
 As a staged model.

Each process area is formally assessed against specific goals and practices and is rated
according to the following capability levels.

Level 0: Incomplete. The process area is either not performed or does not achieve all
goals and objectives defined by CMMI for level 1 capability.
Level 1: Performed. All of the specific goals of the process area have been satisfied.
Work tasks required to produce defined work products are being conducted.
Level 2: Managed. All level 1 criteria have been satisfied. In addition, all work
associated with the process area conforms to an organizationally defined policy; all
people doing the work have access to adequate resources to get the job done;
stakeholders are actively involved in the process area as required; all work tasks and
work products are monitored, controlled, and reviewed;

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 11

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Level 3: Defined. All level 2 criteria have been achieved. In addition, the process is
tailored from the organizations set of standard processes according to the
organizations tailoring guidelines, and contributes and work products, measures and
other process-improvement information to the organizational process assets‖.

Level 4: Quantitatively managed. All level 3 criteria have been achieved. In addition,
the process area is controlled and improved using measurement and quantitative
assessment. Quantitative objectives for quality and process performance are
established and used as criteria in managing the process‖

Level 5: Optimized. All level 4 criteria have been achieved. In addition, the process
area is adapted and optimized using quantitative means to meet changing customer
needs and to continually improve the efficacy of the process area under consideration

The CMMI defines each process area in terms of ―specific goals and the ―specific
practices required to achieve these goals. Specific practices refine a goal into a set of
process-related activities.

The specific goals (SG) and the associated specific practices(SP) defined for project
planning are
SG 1 Establish estimates
SP 1.1 Estimate the scope of the project
SP 1.2 Establish estimates of work product and task attributes SP 1.3 Define project
life cycle
SP 1.4 Determine estimates of effort and cost

SG 2 Develop a Project Plan

SP 2.1 Establish the budget and schedule SP 2.2 Identify project risks
SP 2.3 Plan for data management
SP 2.4 Plan for needed knowledge and skills SP 2.5 Plan stakeholder involvement
SP 2.6 Establish the project plan
SG 3 Obtain commitment to the plan
SP 3.1 Review plans that affect the project SP3.2 Reconcile work and resource levels
SP 3.3 Obtain plan commitment

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 12

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

In addition to specific goals and practices, the CMMI also defines a set of five
generic goals and related practices for each process area. Each of the five generic
goals corresponds to one of the five capability levels. Hence to achieve a particular
capability level, the generic goal for that level and the generic practices that
correspond to that goal must be achieved. To illustrate, the generic goals (GG) and
practices (GP) for the project planning process area are

GG 1 Achieve specific goals

GP 1.1 Perform base practices

GG 2 Institutionalize a managed process

GP 2.1 Establish and organizational policy GP 2.2 Plan the process
GP 2.3 Provide resources
GP 2.4 Assign responsibility GP 2.5 Train people GP 2.6 Manage configurations
GP 2.7 Identify and involve relevant stakeholders GP 2.8 Monitor and control the
process
GP 2.9 Objectively evaluate adherence
GP 2.10 Review status with higher level management

GG 3 Institutionalize a defined process

GP 3.1 Establish a defined process
GP 3.2 Collect improvement information

GG 4 Institutionalize a quantitatively managed process

GP 4.1 Establish quantitative objectives for the process
GP 4.2 Stabilize sub process performance GG 5 Institutionalize and optimizing
process
GP 5.1 Ensure continuous processimprovement GP 5.2 Correct root causes of
problems

PROCESS PATTERNS
The software process can be defined as a collection patterns that define a set of
activities, actions, work Tasks, work products and/or related behaviors required to
develop computer software.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 13

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

A process pattern provides us with a template- a consistent method for

describing an important characteristic of the software process. A pattern might be
used to describe a complete process and a task within a framework activity.
Pattern Name: The pattern is given a meaningful name that describes its function
within the software process.
Intent: The objective of the pattern is described briefly.
Type: The pattern type is specified. There are three types
 Task patterns define a software engineering action or work task that is part of the
process and relevant to successful software engineering practice.
Example: Requirement Gathering
 Stage Patterns define a framework activity for the process. This pattern
incorporates multiple task patterns that are relevant to the stage.
Example: Communication
 Phase patterns define the sequence of framework activities that occur with the
process, even when the overall flow of activities is iterative in nature.
Example: Spiral model or prototyping.

Initial Context: The conditions under which the pattern applies are described prior to
the initiation of the pattern, we ask
(1) What organizational or team related activities have already occurred.
(2) What is the entry state for the process
(3) What software engineering information or project information already exists

Problem: The problem to be solved by the pattern is described.

Solution: The implementation of the pattern is described.
This section describes how the initial state of the process is modified as a consequence
the initiation of the pattern.
It also describes how software engineering information or project information that is
available before the initiation of the pattern is transformed as a consequence of the
successful execution of the pattern

Resulting Context: The conditions that will result once the pattern has been
successfully implemented are described. Upon completion of the pattern we ask

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 14

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

(1) What organizational or team-related activities must have occurred

(2) What is the exit state for the process
(3) What software engineering information or project information has been
developed? begins at a high-level of abstraction.

Known Uses: The specific instances in which the pattern is applicable are indicated
Process patterns provide and effective mechanism for describing any software process.
The patterns enable a software engineering organization to develop a hierarchical
process description that
Once process pattern have been developed, they can be reused for the
definition of process variants-that is, a customized process model can be defined by a
software team using the pattern as building blocks for the process models.

PROCESS ASSESSMENT

Figure 1.2

The existence of a software process is no guarantee that software will be

delivered on time, that it will meet the customer‘s needs, or that it will exhibit the
technical characteristics that will lead to long-term quality characteristics. In addition,
the process itself should be assessed to be essential to ensure that it meets a set of
basic process criteria that have been shown to be essential for a successful software
engineering. A Number of different approaches to software process assessment have
been proposed over the past few decades.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 15

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Standards CMMI Assessment Method for Process Improvement (SCAMPI)

provides a five step process assessment model that incorporates initiating, diagnosing,
establishing, acting & 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,
using the SEI CMM as the basis for the assessment.

SPICE (ISO/IEC15504) standard defines a set of requirements for software process

assessments. 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 is a generic standard that applies to any organization
that wants to improve the overall quality of the products, system, or services that it
provides. Therefore, the standard is directly applicable to software organizations &
companies.

PERSONAL AND TEAM PROCESS MODELS:

The best software process is one that is close to the people who will be doing
the work. Each software engineer would create a process that best fits his or her needs,
and at the same time meets the broader needs of the team and the organization.
Alternatively, the team itself would create its own process, and at the same time meet
the narrower needs of individuals and the broader needs of the organization.

Personal software process (PSP)

The personal software process (PSP) emphasizes personal measurement of both the
work product that produced and the resultant quality of the work product. The PSP
process model defines five framework activities: planning, high-level design, high
level design review, development, and postmortem.

Planning: This activity isolates requirements and, base on these 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.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 16

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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
task 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
the process to improve its effectiveness.

PSP stresses the need for each software engineer to identify errors early and, as
important, to understand the types of errors that he is likely to make. PSP represents a
disciplined, metrics-based approach to software engineering.

Team software process (TSP): The goal of TSP is to build a ―self-directed project
team that organizes itself to produce high-quality software. The following are the
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(IPT) 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 teamskills.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 17

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

A self-directed team defines

 roles and responsibilities for each team member
 tracks quantitative project data
 identifies a team process that is appropriate for the project
 a strategy for implementing the process
 defines local standards that are applicable to the teams software engineering work;
 continually assesses risk and reacts to it
 Tracks, manages, and reports project status.

TSP defines the following framework activities: 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.

Each project is ―launched‖ using a sequence of tasks. The following launch

script is recommended
 Review project objectives with management and agree on and document team
goals
 Establish team roles
 Define the teams development process
 Make a quality plan and set quality targets
 Plan for the needed support facilities

PROCESS MODELS
Prescriptive process models define a set of activities, actions, tasks,
milestones, and work products that are required to engineer high-quality software.
These process models are not perfect, but they do provide a useful roadmap for
software engineering work.

THE WATERFALL MODEL:

The waterfall model, sometimes called the classic life cycle, suggests a
systematic sequential approach to software development that begins with customer
specification of requirements and progresses through planning, modeling,
construction, and deployment.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 18

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Context: Used when requirements are reasonably well understood

Advantage:
It can serve as a useful process model in situations where requirements are fixed and
work is to proceed to complete in a linear manner.

Figure 1.3

The problems that are sometimes encountered when the waterfall model is applied are
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.

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
exist at the beginning of many projects.

The customer must have patience. A working version of the programs will not be
available until late in the project time-span. If a major blunder is undetected then it
can be disastrous until the program is reviewed.

INCREMENTAL PROCESS MODELS:

The incremental model , The RAD model

THE INCREMENTAL MODEL:

Context: Incremental development is particularly useful when staffing is unavailable
for a complete implementation by the business deadline that has been established for
the project. Early increments can be implemented with fewer people. If the core
product is well received, additional staff can be added to implement the next
increment. In addition, increments can be planned to manage technical risks.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 19

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 1.4

The incremental model combines elements of the waterfall model applied in

an iterative fashion. The incremental model delivers a series of releases called
increments that provide progressively more functionality for the customer as each
increment is delivered. When an incremental model is used, the first increment is often
a core product. That is basic requirements are addressed. The core product is used by
the customer. As a result, 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.

For example, word-processing software developed using the incremental

paradigm might deliver basic file management editing, and document production
functions in the first increment; more sophisticated editing, and document production
capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment.

Difference: The incremental process model, like prototyping and other evolutionary
approaches, is iterative in nature. But unlike prototyping, the incremental model
focuses on delivery of an operational product with each increment

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 20

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

THE RAD MODEL:

Rapid Application Development (RAD) is an incremental software process model
that emphasizes a short development cycle. The RAD model is a “high-speed”
adaption of the waterfall model, in which rapid development is achieved by using a
component base construction approach.

Figure 1.5 RAD Model

Context: If requirements are well understood and project scope is constrained, the
RAD process enables a development team to create a “fully functional system” within
a very short time period.

The RAD approach maps into the generic framework activities.

Communication works to understand the business problem and the information

characteristics that the software must accommodate.

Planning is essential because multiple software teams works in parallel on different

system functions.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 21

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Modeling encompasses three major phases – business modeling, data modeling and
process modeling and establishes design representation that server existing software
components and the application of automatic code generation.

Deployment establishes a basis for subsequent iterations. The RAD approach has
drawbacks:
If developers and customers are not committed to the rapid-fire activities necessary to
complete the system in a much abbreviated time frame, RAD projects will fail
If a system cannot be properly modularized, building the components necessary for
RAD will problematic
If high performance is an issue, and performance is to be achieved through tuning the
interfaces to system components, the RAD approach may not work; and
RAD may not be appropriate when technical risks are high.

EVOLUTIONARY PROCESS MODELS:

Evolutionary process models produce with each iteration produce an
increasingly more complete version of the software with every iteration. Evolutionary
models are iterative. They are characterized in a manner that enables software
engineers to develop increasingly more complete versions of the software.

PROTOTYPING:
Prototyping is more commonly used as a technique that can be implemented
within the context of anyone of the process model.

The prototyping paradigm begins with communication. The software engineer

and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is
mandatory.

Prototyping iteration is planned quickly and modeling occurs. The quick

design leads to the construction of a prototype. The prototype is deployed and then
evaluated by the customer/user.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 22

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 1.6 : Prototyping Model

Iteration occurs as the prototype is tuned to satisfy the needs of the customer,
while at the same time enabling the developer to better understand what needs to be
done.
If a customer defines a set of general objectives for software, but does not identify
detailed input, processing, or output requirements, in such situation prototyping
paradigm is best approach.
If a developer may be unsure of the efficiency of an algorithm, the adaptability of an
operating system then he can go for this prototyping method.

Advantages:
The prototyping paradigm assists the software engineer and the customer to
better understand what is to be built when requirements are fuzzy.

The prototype serves as a mechanism for identifying software requirements. If

a working prototype is built, the developer attempts to make use of existing program
fragments or applies tools.

Prototyping can be problematic for the following reasons:

The customer sees what appears to be a working version of the software,
unaware that the prototype is held together “with chewing gum and baling wire”,

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 23

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

unaware that in the rush to get it working we haven’t considered overall software
quality or long-term maintainability. When informed that the product must be rebuilt
so that high-levels of quality can be maintained, the customer cries foul and demands
that “a few fixes” be applied to make the prototype a working product. Too often,
software development relents.

The developer often makes implementation compromises in order to get a

prototype working quickly. An inappropriate operating system or programming
language may be used simply because it is available and known; an inefficient
algorithm may be implemented simply to demonstrate capability. After a time, the
developer may become comfortable with these choices and forget all the reasons why
they were inappropriate. The less-than-ideal choice has now become an integral part
of the system.

THE SPIRAL MODEL

The spiral model, originally proposed by Boehm, is an evolutionary software
process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model. The spiral model can be adapted to apply
throughout the entire life cycle of an application, from concept development to
maintenance.

Using the spiral model, software is developed in a series of evolutionary

releases. During early iterations, the release might be a paper model or prototype.
During later iterations, increasingly more complete versions of the engineered system
are

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.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 24

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 1.7 : Spiral Model

The first circuit around the spiral might result in the development of 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.

It maintains the systematic stepwise approach suggested by the classic life

cycle but incorporates it into an iterative framework that more realistically reflects the
real world.

The first circuit around the spiral might represent a “concept development
project” which starts at the core of the spiral and continues for multiple iterations until
concept development is complete.

If the concept is to be developed into an actual product, the process proceeds

outward on the spiral and a “new product development project” commences.

Later, a circuit around the spiral might be used to represent a “product

enhancement project.” In essence, the spiral, when characterized in this way, remains
operative until the software is retired.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 25

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Context: The spiral model can be adopted to apply throughout the entire life cycle of
an application, from concept development to maintenance.

Advantages:
 It provides the potential for rapid development of increasingly more complete
versions of the software.
 The spiral model is a realistic approach to the development of large-scale systems
and software. The spiral model uses prototyping as a risk reduction mechanism
but, more importantly enables the developer to apply the prototyping approach at
any stage in the evolution of the product.

Draw Backs:
The spiral model is not a panacea. It may be difficult to convince customers that the
evolutionary approach is controllable. It demands considerable risk assessment
expertise and relies on this expertise for success. If a major risk is not uncovered and
managed, problems will undoubtedly occur.

THE CONCURRENT DEVELOPMENT MODEL:

The concurrent development model, sometimes called concurrent engineering,
can be represented schematically as a series of framework activities, software
engineering actions and tasks, and their associated states.

The activity modeling may be in anyone of the states noted at any given time.
Similarly, other activities or tasks can be represented in an analogous manner. All
activities exist concurrently but reside in different states.

Any of the activities of a project may be in a particular state at any one time:
 under development
 awaiting changes
 under revision
 under review

In a project the communication activity has completed its first iteration and
exists in the awaiting changes state. The modeling activity which existed in the none
state while initial communication was completed, now makes a transition into the

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 26

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

under development state. If, however, the customer indicates that changes in
requirements must be made, the modeling activity moves from the under development
state into the awaiting changes state.

The concurrent process model defines a series of events that will trigger
transitions from state to state for each of the software engineering activities, actions,
or tasks. The event analysis model correction which will trigger the analysis action
from the done state into the awaiting changes state.

Context: The concurrent model is often more appropriate for system engineering
projects where different engineering teams are involved.

Advantages:
 The concurrent process model is applicable to all types of software development
and provides an accurate picture of the current state of a project.
 It defines a network of activities rather than each activity, action, or task on the
network exists simultaneously with other activities, action and tasks.

A FINAL COMMENT ON EVOLUTIONARY PROCESSES:

The concerns of evolutionary software processes are:
The first concern is that prototyping poses a problem to project planning
because of the uncertain number of cycles required to construct the product.

Second, evolutionary software process do not establish the maximum speed of

the evolution. If the evolution occurs too fast, without a period of relaxation, it is
certain that the process will fall into chaos.

Third, software processes should be focused on flexibility and extensibility

rather than on high quality.

1.13 SPECIALIZED PROCESS MODELS

Component-Based Development
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

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 27

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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.

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 clean room software engineering.

When formal methods are used during development, they provide a mechanism
for eliminating many of the problems that are difficult to overcome using other software
engineering paradigms. Ambiguity, incompleteness, and inconsistency can be discovered
and corrected more easily, but through the application of mathematical analysis.

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.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 28

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Draw Backs:
 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.

Aspect-Oriented Software Development

AOSD defines “aspects” that express customer concerns that cut across multiple
system functions, features, and information. 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.”

Grundy provides further discussion of aspects in the context of what he calls

aspect- oriented component engineering (AOCE):

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.

1.14 THE UNIFIED PROCESS:

The unified process (UP) is an attempt to draw on the best features and
characteristics of conventional software process models, but characterize them in a
way 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

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 29

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

on the right goals, such as understandability, reliance to future changes, and reuse“. If
suggests a process flow that is iterative and incremental, providing the evolutionary
feel that is essential in modern software development.

A BRIEF HISTORY:
During the 1980s and into early 1990s, object-oriented (OO) methods and
programming languages gained a widespread audience throughout the software
engineering community. A wide variety of object-oriented analysis (OOA) and design
(OOD) methods were proposed during the same time period.

During the early 1990s James Rumbaugh, Grady Booch, and Ival Jacobsom
began working on a “Unified method” that would combine the best features of each of
OOD & OOA. The result was UML- a unified modeling language that contains a
robust notation fot the modeling and development of OO systems.

By 1997, UML became an industry standard for object-oriented software

development. At the same time, the Rational Corporation and other vendors
developed automated tools to support UML methods.

Over the next few years, Jacobson, Rumbugh, and Booch developed the
Unified process, a framework for object-oriented software engineering using UML.
Today, the Unified process and UML are widely used on OO projects of all kinds.
The iterative, incremental model proposed by the UP can and should be adapted to
meet specific project needs.

PHASES OF THE UNIFIED PROCESS:

The inception phase of the UP encompasses both customer communication
and planning activities. By collaborating with the customer and end-users, business
requirements for the software are identified, a rough architecture for the system is
proposed and a plan for the iterative, incremental nature of the ensuing project is
developed.

The elaboration phase encompasses the customer communication and

modeling activities of the generic process model. Elaboration refines and expands the
preliminary use-cases that were developed as part of the inception phase and expands

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 30

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

the architectural representation to include five different views of the software- the use-
case model, the analysis model, the design model, the implementation model, and the
deployment model.

The construction phase of the UP is identical to the construction activity

defined for the generic software process. Using the architectural model as input, the
construction phase develops or acquires the software components that will make each
use-case operational for end-users. To accomplish this, analysis and design models
that were started during the elaboration phase are completed to reflect the final
version of the software increment.

The transition phase of the UP encompasses the latter stages of the generic
construction activity and the first part of the generic deployment activity. Software
given to end-users for beta testing, and user feedback reports both defects and
necessary changes.

The production phase of the UP coincides with the deployment activity of the
generic process. During this phase, the on-going use of the software is monitored,
support for the operating environment is provided, and defect reports and requests for
changes are submitted and evaluated.

Understand the Agile View of Process: Agility and Agile Process models
of Agile Development and Tools.

What is Agile?
Agile methodologies are approaches to product development that are aligned
with the values and principles described in the Agile Manifesto for software
development. Agile methodologies aim to deliver the right product, with incremental
and frequent delivery of small chunks of functionality, through small cross-functional
self-organizing teams, enabling frequent customer feedback and course correction as
needed.

In doing so, Agile aims to right the challenges faced by the traditional
“waterfall” approaches of delivering large products in long periods of time, during

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 31

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

which customer requirements frequently changed, resulting in the wrong products

being delivered.

“Agility is principally about mindset, not practices.” – Jim Highsmith

Agile has become an umbrella term for a variety of planning, management and
technical methods and processes for managing projects, developing software and
other products and services in an iterative manner. These methods include Scrum, by
far the most prevalent and popular method for software, XP (eXtreme Programming
or Paired Programming), and more lately Kanban.

Agile methods also include technical practices – most of which fall under the
umbrella term DevOps – that enable Test Automation, Continuous Integration/
Continuous Delivery/ Deployment (CI/ CD) and overall, an ever-shrinking delivery
cycle for software and other products and services.

What is the Agile Manifesto?

The Agile Manifesto is a statement of core values and principles for software
development. The Agile Manifesto for software development was set up in 2001 and
it is a declaration of 4 vital rules and 12principles that serve as a guide for people
in agile software development. It was created by 17 professionals who already
practiced agile methods such as XP, DSDM, SCRUM, FDD, etc, gathered in the
snowy mountains of the US state of Utah, convened by Kent Beck.

12 PRINCIPLES OF THE AGILE MANIFESTO

1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Businesspeople and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 32

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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.16 Agile Process models of Agile Development and Tools.

Key Agile Methodologies
Agile is an umbrella term for several methods and practices. Let’s look at
some of the popular methodologies:
 Scrum
 Extreme Programming (XP)
 Adaptive Software Development (ASD)
 Dynamic Software Development Method (DSDM)
 Feature Driven Development (FDD)
 Kanban
 Behavior Driven Development (BDD)

Figure 1.8

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 33

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Scrum Methodology
Scrum methodology is a simple framework for working with complex
projects, and it was created by Ken Schwaber and Jeff Sutherland.

Agile software development methodologies are iterative, meaning the work is

divided into iterations, which are called Sprints in the case of Scrum. Scrum is
executed by small teams of between 7-9 people, including a Scrum Master and a
Product Owner.

In Scrum, projects are divided into cycles (typically 2 or 3 week cycles) called
Sprints. The Sprint represents a timebox within which a set of features must be
developed. Multiple sprints might be combined to form a Release – where formal
software/ product delivery is made to the customer/ market.

The overall product functionality is broken down by the Product Owner into
smaller features (typically described as Epics and User Stories – or just Stories).
These Stories are prioritized and taken up in each Sprint or Iteration. The intent of the
method is for the team to be able to demo at the end of each Sprint working pieces of
the product to the Product Owner, to make sure that the product is working as
intended.

Overall, the Scrum method breaks the long waterfall process delivery into
smaller cycles, which enables product teams and the end-customer to frequently
review working software and ensure that it meets their business requirements. This
ensures that the end product also meets the final requirements of the customer.

The Scrum method is characterized by specific ceremonies such as the Daily

Standup meeting, the Sprint Review Meeting, the Demo to the Product Owner and the
Sprint Retrospective meeting. All of these meetings provide collaboration and review
opportunities to the team to ensure that development is progressing as intended, and
any issues are resolved quickly.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 34

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Extreme Programming (XP)

Extreme Programming (XP) – or Paired Programming is a methodology
developed by Kent Beck in the early 90s. This agile methodology focuses on
enhancing interpersonal relationships as a key to success in software development. XP
also focuses on promoting teamwork, caring for the learning of developers, and
fostering a good working environment. It is characterized by developers working in
pairs where one developer programs while the other developer observes; and they
switch these roles on a regular basis throughout the Sprint. This way, they enable
continuous code review and feedback that enhances code quality and developer
capability.

Extreme Programming (XP) promotes continuous feedback between the client

and the development teams, fluid communication between all participants, simplicity
in the implemented solutions and the readiness to face changes. XP is especially
suitable for projects with indistinct and highly changing requirements, and where
there is high technical risk.

Adaptive Software Development (ASD)

Adaptive Software Development (ASD) was developed by Jim Highsmith and
Sam Bayer in the early 1990s. It incorporates the principles of continuous adaptation,
i.e., adapt to change and not fight against it. Adaptive Software Development uses a
dynamic development cycle known as Speculate, Collaborate, and Learn. This cycle
is dedicated to constant learning and intense collaboration between developers and
customers due to the constant change in the business environment.

Unlike most Software development methodologies which use a static life cycle
i.e., Plan-Design-Build, ASD offers a non-linear iterative life cycle, where each cycle
can iterate and be modified while another cycle is being executed. It points towards
Rapid Application Development (RAD), which emphasizes development speed to
create a high quality, low maintenance product involving the user as much as
possible. The main characteristics of ASD are:
1. Speculate: This is the initiation phase of the project where it is necessary to
establish the main objectives and goals of the project by understanding the
limitations (risk areas) with which the project operates.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 35

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

2. Collaborate: This is the phase where most of the development is centered,

maintaining co-ordination between teams that ensures what is learned by one team
is communicated to the rest and does not have to be learned again by other teams
from scratch.
3. Learn: The last stage ends with a series of collaboration cycles – the job is to
capture what has been learned, both positive and negative. This stage is critical for
the effectiveness of the project.

Dynamic Software Development Method (DSDM)

Dynamic Software Development Method (DSDM) was developed in the year
1994 by a group of vendors and experts in the field of Software development. DSDM
focuses on Software projects that are characterized by tight budgets and schedules. It
focuses on frequent delivery of product cycles, and development is iterative and
incremental.

With Dynamic Software Development Method (DSDM), one can design a

roadmap of early and continuous deliveries for the project, implementing an
incremental solution, adapting from the feedback obtained throughout the process,
and checking that the expected benefits are being met.

DSDM is an agile model that can undoubtedly help organizations that are used
to working on projects to change their mentality and way of working to improve their
capacity to deliver value and reduce time to market.

Feature Driven Development (FDD)

Feature Driven Development (FDD) methodology is mainly oriented for larger
teams with more people than those to whom other agile methodologies such as Scrum
are normally applied. FDD was developed by Jeff De Luca and Peter Coad in the year
1997. This methodology focuses on short iterations, which allow tangible deliveries
of the product in a short period of time (2 weeks).

Projects with multiple teams and a large number of people represent the
challenge that not all will be equally talented and disciplined. FDD includes specific
activities that help address communication challenges and coordination of such
projects.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 36

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

FDD is a 5-stage process, the first 3 of which are sequential and the final two
stages are iterative (as shown in the diagram above). All agile methodologies follow a
series of principles that make them resemble each other. FDD, however, offers
solutions on how to organize the team and how to program the code, which makes it
especially viable for large development teams building complex software.

Kanban Method
The Kanban Method was defined by David Anderson in the early -to-mid
2000s, in response to some of the challenges of the various Agile methods, especially
Scrum. These methods, while trying to solve the challenges of traditional/ waterfall
methods, became victim to some of the same challenges themselves.

The 2-3 week sprint cycle became too long to wait for many business contexts,
the changes required in organizational structure (new roles and responsibilities) and a
project management/ planning processes put too much strain on organizations, and
many teams found themselves not meeting even sprint-level commitments of scope
and quality. For most organizations, implementing these methods became very
disruptive.

The Kanban Method was defined as the opposite of that – a non-disruptive

evolutionary method for improvement, that ultimately enables teams to deliver
continuously instead of in time-buckets of 2-3 weeks, get feedback faster and reduce
the lead time to deliver value to the customer.

Kanban is a visual system for managing work as it moves through a

process. Kanban visualizes both the process (the workflow) and the actual work
passing through that process. The goal of Kanban is to identify potential bottlenecks
in your process and fix them, so work can flow through it cost-effectively at an
optimal speed or throughput.

Kanban is defined as a highly effective and efficient production system. The

origin of the Kanban methodology lies in the “just-in-time” (JIT) production
processes devised by Toyota, in which cards were used to identify material needs in
the production chain.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 37

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Behavior Driven Development (BDD)

Behavior Driven Development (BDD) is a behavior-oriented agile
development methodology. It was created by Dan North in 2003 as an evolution of
the TDD methodology. Dan North aimed to bring non-technical people together in the
process of creating the system’s technical functionality. It happens that when we
develop software, we involuntarily fail to include business concepts present in the
functionality, resulting in a possible flow for recurring and even serious bugs.

BDD uses universal language concepts that encourage collaboration between

people with or without technical knowledge in a software project. The BDD
development process is based on writing test scenarios and features. These contain the
requirements and acceptance criteria for the system behavior. It tells you what the
functionality needs to get started, what it will do next, and what the results will be
after it is executed.

BDD helps teams more accurately communicate requirements, discover

defects early, and build software that remains sustainable over time.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 38

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT-II
FUNCTIONAL AND NON- FUNCTIONAL REQUIREMENTS

Software requirements are necessary

 To introduce the concepts of user and system requirements
 To describe functional and non-functional requirements
 To explain how software requirements may be organized in a requirements
document

What is a requirement?
 The requirements for the system are the description of the services provided by
the system and its operational constraints
 It may range from a high-level abstract statement of a service or of a system
constraint to a detailed mathematical functional specification.
 This is inevitable as requirements may serve a dual function

May be the basis for a bid for a contract - therefore must be open to
interpretation; May be the basis for the contract itself - therefore must be defined in
detail;

Requirements engineering:
 The process of finding out, analyzing documenting and checking these services
and constraints is called requirement engineering.
 The process of establishing the services that the customer requires from a system
and the constraints under which it operates and is developed.
 The requirements themselves are the descriptions of the system services and
constraints that are generated during the requirements engineering process.

Requirements abstraction (Davis):

If a company wishes to let a contract for a large software development project,
it must define its needs in a sufficiently abstract way that a solution is not pre-defined.
The requirements must be written so that several contractors can bid for the contract,
offering, perhaps, different ways of meeting the client organization’s needs. Once a

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 39

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

contract has been awarded, the contractor must write a system definition for the client
in more detail so that the client understands and can validate what the software will
do. Both of these documents may be called the requirements document for the system.

Types of Requirements:
User requirements
 Statements in natural language plus diagrams of the services the system provides
and its operational constraints. Written for customers.

System requirements
 A structured document setting out detailed descriptions of the system’s functions,
services and operational constraints. Defines what should be implemented so may
be part of a contract between client and contractor.

DEFINITIONS AND SPECIFICATIONS:

User Requirement Definition:
The software must provide the means of representing and accessing external
files created by other tools.

System Requirement specification:

 The user should be provided with facilities to define the type of external files.

 Each external file type may have an associated tool which may be applied to the
file.

 Each external file type may be represented as a specific icon on the user’s display.

 Facilities should be provided for the icon representing an external file type to be
defined by the user.

 When an user selects an icon representing an external file, the effect of that
selection is to apply the tool associated with the type of the external file to the file
represented by the selected icon.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 40

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Requirements readers:
Functional and Non-Functional Requirements:

Figure 2.1
Functional requirements
 Statements of services the system should provide how the system should react to
particular inputs and how the system should behave in particular situations.

Non-functional requirements
 Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.

Domain requirements
 Requirements that come from the application domain of the system and that reflect
characteristics of that domain.

FUNCTIONAL REQUIREMENTS:
 Describe functionality or system services.
 Depend on the type of software, expected users and the type of system where the
software is used.
 Functional user requirements may be high-level statements of what the system
should do but functional system requirements should describe the system services
in detail.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 41

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The functional requirements for The LIBSYS system:

 A library system that provides a single interface to a number of databases of
articles in different libraries.
 Users can search for, download and print these articles for personal study.

Examples of functional requirements

 The user shall be able to search either all of the initial set of databases or select a
subset from it.
 The system shall provide appropriate viewers for the user to read documents in the
document store.
 Every order shall be allocated a unique identifier (ORDER_ID) which the user
shall be able to copy to the account’s permanent storage area.

Requirements imprecision:
 Problems arise when requirements are not precisely stated.
 Ambiguous requirements may be interpreted in different ways by developers and
users.
 Consider the term ‘appropriate viewers’
 User intention - special purpose viewer for each different document type;
 Developer interpretation - Provide a text viewer that shows the contents of the
document.

Requirements completeness and consistency:

In principle, requirements should be both complete and consistent.
Complete:
 They should include descriptions of all facilities required.

Consistent:
 There should be no conflicts or contradictions in the descriptions of the system
facilities. In practice, it is impossible to produce a complete and consistent
requirements document.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 42

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

NON-FUNCTIONAL REQUIREMENTS
 These define system properties and constraints e.g. reliability, response time and
storage requirements. Constraints are I/O device capability, system representations,
etc.
 Process requirements may also be specified mandating a particular CASE system,
programming language or development method.
 Non-functional requirements may be more critical than functional requirements. If
these are not met, the system is useless.

Non-functional requirement types:

Figure 2.2

Non-functional requirements :
Product requirements
 Requirements which specify that the delivered product must behave in a particular
way
E.g. execution speed, reliability, etc.
Eg: The user interface for LIBSYS shall be implemented as simple HTML without
frames or Java applets.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 43

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Organizational requirements
 Requirements which are a consequence of organizational policies and procedures
E.g. process standards used, implementation requirements, etc.
Eg: The system development process and deliverable documents shall conform to
the process and deliverables defined in XYZCo-SP-STAN-95.

External requirements
 Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements,
etc.
 Eg: The system shall not disclose any personal information about customers apart
from their name and reference number to the operators of the system.

Goals and requirements:

Non-functional requirements may be very difficult to state precisely and
imprecise requirements may be difficult to verify.

Goals
 A general intention of the user such as ease of use.
 The system should be easy to use by experienced controllers and should be
organised in such a way that user errors are minimized.

Verifiable non-functional requirement

 A statement using some measure that can be objectively tested.
 Experienced controllers shall be able to use all the system functions after a total of
two hours training. After this training, the average number of errors made by
experienced users shall not exceed two per day.
 Goals are helpful to developers as they convey the intentions of the system users.

Requirements interaction:
 Conflicts between different non-functional requirements are common in complex
systems. Spacecraft system
 To minimize weight, the number of separate chips in the system should be
minimized. To minimize power consumption, lower power chips should be used.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 44

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 However, using low power chips may mean that more chips have to be used.
Which is the most critical requirement?

A common problem with non-functional requirements is that they can be

difficult to verify. Users or customers often state these requirements as general goals
such as ease of use, the ability of the system to recover from failure or rapid user
response. These vague goals cause problems for system developers as they leave
scope for interpretation. And subsequent dispute once the system is delivered.

DOMAIN REQUIREMENTS
 Derived from the application domain and describe system characteristics and
features that reflect the domain.
 Domain requirements be new functional requirements, constraints on existing
requirements or define specific computations.
 If domain requirements are not satisfied, the system may be unworkable.

Library system domain requirements:

 There shall be a standard user interface to all databases which shall be based on
the Z39.50 standard.
 Because of copyright restrictions, some documents must be deleted immediately
on arrival.

Depending on the user’s requirements, these documents will either be printed

locally on the system server for manually forwarding to the user or routed to a
network printer.

Train protection system

The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated gradient / alpha and where the values of
9.81ms2/alpha are known for different types of train.

Domain requirements problems Understandability

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 45

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 Requirements are expressed in the language of the application domain;

 This is often not understood by software engineers developing the system.

Implicitness
 Domain specialists understand the area so well that they do not think of making
the domain requirements explicit.

USER REQUIREMENTS
 Should describe functional and non-functional requirements in such a way that
they are understandable by system users who don’t have detailed technical
knowledge.
 User requirements are defined using natural language, tables and diagrams as
these can be understood by all users.

Problems with natural language Lack of clarity

Precision is difficult without making the document difficult to read.

Requirements confusion
Functional and non-functional requirements tend to be mixed-up.

Requirements amalgamation
Several different requirements may be expressed together.

Editor grid requirement

Grid facilities To assist in the positioning of entities on a diagram, the user may turn
on a grid in either centimetres or inches, via an option on the control panel. Initially,
the grid is off. The grid may be turned on and off at any time during an editing session
and can be toggled between inches and centimetres at any time. A grid option will be
provided on the reduce- to-fit view but the number of grid lines shown will be reduced
to avoid filling the smaller diagram with grid lines.

Requirement problems
Database requirements includes both conceptual and detailed information
 Describes the concept of a financial accounting system that is to be included in
LIBSYS;

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 46

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 However, it also includes the detail that managers can configure this system - this
is unnecessary at this level.

Grid requirement mixes three different kinds of requirement

 Conceptual functional requirement (the need for a grid);
 Non-functional requirement (grid units);
 Non-functional UI requirement (grid switching).
 Structured presentation

STRUCTURED PRESENTATION
2.6.1 Grid Facilities

Guidelines for writing requirements

 Invent a standard format and use it for all requirements.
 Use language in a consistent way. Use shall for mandatory requirements, should
for desirable requirements.
 Use text highlighting to identify key parts of the requirement.

SYSTEM REQUIREMENTS
 More detailed specifications of system functions, services and constraints than
user requirements.
 They are intended to be a basis for designing the system.
 They may be incorporated into the system contract.
 System requirements may be defined or illustrated using system models

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 47

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Requirements and design

In principle, requirements should state what the system should do and the design
should describe how it does this.
In practice, requirements and design are inseparable
 A system architecture may be designed to structure the requirements;
 The system may inter-operate with other systems that generate design requirements;
 The use of a specific design may be a domain requirement.

Problems with NL(natural language) specification Ambiguity

 The readers and writers of the requirement must interpret the same words in the
same way. NL is naturally ambiguous so this is very difficult.

Over-flexibility
 The same thing may be said in a number of different ways in the specification.
Lack of modularization
 NL structures are inadequate to structure system requirements.

Alternatives to NL specification:
Notation Description
Structured natural This approach depends on defining standard forms or templates
Language Requirement Analysis
Design description This approach uses a language like a programming language but
with more abstract
Languages Features to specify the requirements by defining an operational
model of the system.

This approach is not now widely used although it can be useful for interface
specifications. Graphical A graphical language, supplemented by text annotations is
used to define the functional notations requirements for the system. An early example
of such a graphical language was SADT. Now, use-case descriptions and sequence
diagrams are commonly used.
Mathematical: These are notations based on mathematical concepts such as finite-
state machines or specifications sets. These unambiguous specifications reduce the
arguments between customer and contractor about system functionality. However,
most customers don’t understand formal specifications and are reluctant to accept it as
a system contract.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 48

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Structured language specifications

 A limited form of natural language may be used to express requirements
 This removes some of the problems resulting from ambiguity and flexibility and
imposes a degree of uniformity on a specification
 Often best supported using a forms-based approach
 The freedom of the requirements writer is limited by a predefined template for
requirements.
 All requirements are written in a standard way.
 The terminology used in the description may be limited.
 The advantage is that the most of the expressiveness of natural language is
maintained but a degree of uniformity is imposed on the specification.

Form-based specifications
 Definition of the function or entity.
 Description of inputs and where they come from.
 Description of outputs and where they go to.
 Indication of other entities required.
 Pre and post conditions (if appropriate).
 The side effects (if any) of the function.

Form-based node specification

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 49

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

When a standard form is used for specifying functional requirements, the following
information should be included:
1. Description of the function or entity being specified
2. Description of its inputs and where these come from
3. Description of its outputs and where these go to
4. Indication of what other entities are used
5. Description of the action to be taken
6. If a functional approach is used, a pre-condition setting out what must be true
before the function is called and a post-condition specifying what is true after the
function is called
7. Description of the side effects of the operation.

Tabular specification
 Used to supplement natural language.
 Particularly useful when you have to define a number of possible alternative
courses of action.

Graphical models
 Graphical models are most useful when you need to show how state changes or
where you need to describe a sequence of actions.

Sequence diagrams
 These show the sequence of events that take place during some user interaction
with a system.
 You read them from top to bottom to see the order of the actions that takeplace.
 Cash withdrawal from an ATM

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 50

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 Validate card;
 Handle request;
 Complete transaction.

Sequence diagram of ATM withdrawal

Figure 2.3

INTERFACE SPECIFICATION
Most systems must operate with other systems and the operating interfaces must be
specified as part of the requirements.

Three types of interface may have to be defined

 Procedural interfaces where existing programs or sub-systems offer a range of
services that are accessed by calling interface procedures. These interfaces are
sometimes called Application Programming Interfaces (APIs)
 Data structures that are exchanged that are passed from one sub-system to
another. Graphical data models are the best notations for this type of description
 Data representations that have been established for an existing sub-system
Formal notations are an effective technique for interface specification.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 51

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

PDL Interface Descrioption

THE SOFTWARE REQUIREMENTS DOCUMENT:

 The requirements document is the official statement of what is required of the

system developers.

 Should include both a definition of user requirements and a specification of the

system requirements.

 It is NOT a design document. As far as possible, it should set of WHAT the

system should do rather than HOW it should do it

Users of a requirements document:

IEEE requirements standard defines a generic structure for a requirements document
that must be instantiated for each specific system.

1. Introduction.
i) Purpose of the requirements document
ii) Scope of the project
iii) Definitions, acronyms and abbreviations
iv) References
v) Overview of the remainder of the document

2. General description.
i) Product perspective
ii) Product functions

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 52

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

iii) User characteristics

iv) General constraints
v) Assumptions and dependencies

Specific requirements cover functional, non-functional and interface

requirements. The requirements may document external interfaces, describe system
functionality and performance, specify logical database requirements, design
constraints, emergent system properties and quality characteristics.
1. Appendices.
2. Index.

REQUIREMENTS DOCUMENT STRUCTURE

1. Preface
2. Introduction
3. Glossary
4. User requirements definition
5. System architecture
6. System requirements specification
7. System models
8. System evolution
9. Appendices
10.Index

REQUIREMENTS ENGINEERING PROCESSES

The goal of requirements engineering process is to create and maintain a
system requirements document. The overall process includes four high-level
requirement engineering sub-processes. These are concerned with
 Assessing whether the system is useful to the business(feasibility study)
 Discovering requirements(elicitation and analysis)
 Converting these requirements into some standard form(specification)
 Checking that the requirements actually define the system that the customer wants
(validation) The process of managing the changes in the requirements is called
requirement management.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 53

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The requirements engineering process

Requirements engineering:
 The alternative perspective on the requirements engineering process presents the
process as a three-stage activity
 where the activities are organized as an iterative process around a spiral.
 The amount of time and effort devoted to each activity in iteration depends on the
stage of the overall process and the type of system being developed.
 Early in the process, most effort will be spent on understanding high-level business
and non-functional requirements and the user requirements.
 Later in the process, in the outer rings of the spiral, more effort will be devoted to
system requirements engineering and system modeling.

Figure 2.4

SPIRAL MODEL OF REQUIREMENTS ENGINEERING

 This spiral model accommodates approaches to development in which the
requirements are developed to different levels of detail.
 The number of iterations around the spiral can vary, so the spiral can be exited
after some or all of the user requirements have been elicited.
 Some people consider requirements engineering to be the process of applying a
structured analysis method such as object-oriented analysis.
 This involves analyzing the system and developing a set of graphical system
models, such as use-case models, that then serve as a system specification.
 The set of models describes the behavior of the system and are annotated with
additional information describing, for example, its required performance or
reliability.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 54

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 2.5 : Spiral model of requirements engineering processes

REQUIREMENTS ENGINEERING PROCESS FEASIBILITY STUDIES

A feasibility study decides whether or not the proposed system is worthwhile.
 The input to the feasibility study is a set of preliminary business requirements, an
outline description of the system and how the system is intended to support
business processes.
 The results of the feasibility study should be a report that recommends whether or
not it worth carrying on with the requirements engineering and system
development process.
 A short focused study that checks
o If the system contributes to organizational objectives;
o If the system can be engineered using current technology and within budget;
o If the system can be integrated with other systems that are used.

Feasibility study implementation:

 A feasibility study involves information assessment, information collection and
report writing.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 55

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 Questions for people in the organisation

o What if the system wasn’t implemented?
o What are current process problems?
o How will the proposed system help?
o What will be the integration problems?
o Is new technology needed? What skills?
o What facilities must be supported by the proposed system?

In a feasibility study, you may consult information sources such as the

managers of the departments where the system will be used, software engineers who
are familiar with the type of system that is proposed, technology experts and end-
users of the system. They should try to complete a feasibility study in two or three
weeks.

Once you have the information, you write the feasibility study report. You
should make a recommendation about whether or not the system development should
continue. In the report, you may propose changes to the scope, budget and schedule of
the system and suggest further high-level requirements for the system.

REQUIREMENT ELICITATION AND ANALYSIS:

The second step in requirement engineering process is requirements elicitation
and analysis.
 Sometimes called requirements elicitation or requirements discovery.
 Involves technical staff working with customers to find out about the application
domain, the services that the system should provide and the system’s operational
constraints.
 May involve end-users, managers, engineers involved in maintenance, domain
experts, trade unions, etc. These are called stakeholders.

Problems of requirements analysis

 Stakeholders don’t know what they really want.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting requirements.
 Organisational and political factors may influence the system requirements.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 56

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 The requirements change during the analysis process. New stakeholders may
emerge and the business environment change.

The requirements spiral

1. Requirements discovery
Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.

2. Requirements classification and organization

Groups related requirements and organizes them into coherent clusters.
3. Prioritization and negotiation
Prioritising requirements and resolving requirements conflicts.

Figure 2.6 : Process activities

4. Requirements documentation
Requirements are documented and input into the next round of the spiral.
 The process cycle starts with requirements discovery and ends with requirements
documentation. The analyst’s understanding of the requirements improves with
each round of the cycle.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 57

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 Requirements classification and organization is primarily concerned with

identifying overlapping requirements from different stakeholders and grouping
related requirements. The most common way of grouping requirements is to use a
model of the system architecture to identify subsystems and to associate
requirements with each sub- system
 Inevitably, stakeholders have different views on the importance and priority of
requirements, and sometimes these view conflict.
 During the process, you should organize regular stakeholder negotiations so that
compromises can be reached.

In the requirement documenting stage, the requirements that have been elicited
are documented in such a way that they can be used to help with further requirements
discovery.

REQUIREMENTS DISCOVERY:

 Requirement discovery is the process of gathering information about the proposed

and existing systems and distilling the user and system requirements from this
information.

 Sources of information include documentation, system stakeholders and the

specifications of similar systems.

 They interact with stakeholders through interview and observation and may use
scenarios and prototypes to help with the requirements discovery.

 Stakeholders range from system end-users through managers and external

stakeholders such as regulators who certify the acceptability of the system.

For example, system stakeholder for a bank ATM include

1. Bank Customers
2. Representatives of other banks
3. Bank Managers
4. Counter Staff
5. Database Administrators

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 58

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

6. Security Managers
7. Marketing Department
8. Hardware and Software Maintenance Engineers
9. Banking Regulators

Requirements sources( stakeholders, domain, systems) can all be represented

as system viewpoints, where each viewpoints, where each viewpoint presents a sub-
set of the requirements for the system.

Viewpoints:
Viewpoints are a way of structuring the requirements to represent the
perspectives of different stakeholders. Stakeholders may be classified under different
viewpoints. This multi-perspective analysis is important as there is no single correct
way to analyse system requirements.

TYPES OF VIEWPOINT:
1. Interactor viewpoints
People or other systems that interact directly with the system. These
viewpoints provide detailed system requirements covering the system features and
interfaces. In an ATM, the customer’s and the account database are interactor VPs.

2. Indirect viewpoints
Stakeholders who do not use the system themselves but who influence the
requirements. These viewpoints are more likely to provide higher-level organisation
requirements and constraints. In an ATM, management and security staff are indirect
viewpoints.

3. Domain viewpoints
Domain characteristics and constraints that influence the requirements. These
viewpoints normally provide domain constraints that apply to the system. In an ATM,
an example would be standards for inter-bank communications. Typically, these
viewpoints provide different types of requirements.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 59

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Viewpoint identification:
Identify viewpoints using
 Providers and receivers of system services;
 Systems that interact directly with the system being specified;
 Regulations and standards;
 Sources of business and non-functional requirements.
 Engineers who have to develop and maintain the system;
 Marketing and other business viewpoints.

LIBSYS viewpoint hierarchy

Figure 2.7

Interviewing
In formal or informal interviewing, the RE team puts questions to stakeholders
about the system that they use and the system to be developed.

There are two types of interview

 Closed interviews where a pre-defined set of questions are answered.
 Open interviews where there is no pre-defined agenda and a range of issues are
explored with stakeholders.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 60

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Interviews in practice:
 Normally a mix of closed and open-ended interviewing.
 Interviews are good for getting an overall understanding of what stakeholders do
and how they might interact with the system.
 Interviews are not good for understanding domain requirements
 Requirements engineers cannot understand specific domain terminology;
 Some domain knowledge is so familiar that people find it hard to articulate or think
that it isn’t worth articulating.

Effective interviewers:
 Interviewers should be open-minded, willing to listen to stakeholders and
should not have pre-conceived ideas about the requirements.
 They should prompt the interviewee with a question or a proposal and should
not simply expect them to respond to a question such as ‘what do you want’.

Scenarios:
Scenarios are real-life examples of how a system can be used. They should include
 A description of the starting situation;
 A description of the normal flow ofevents;
 A description of what can go wrong;
 Information about other concurrent activities;
 A description of the state when the scenario finishes.

Use cases
 Use-cases are a scenario based technique in the UML which identify the actors in
an interaction and which describe the interaction itself.
 A set of use cases should describe all possible interactions with the system.
 Sequence diagrams may be used to add detail to use-cases by showing the
sequence of event processing in the system.

Article printing use-case:

Figure 2.8

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 61

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

LIBSYS use cases:

Figure 2.9

Article printing sequence:

Figure 2.10

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 62

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

SOCIAL AND ORGANISATIONAL FACTORS

 Software systems are used in a social and organisational context. This can
influence or even dominate the system requirements.
 Social and organisational factors are not a single viewpoint but are influences on
all viewpoints.
 Good analysts must be sensitive to these factors but currently no systematic way to
tackle their analysis.

ETHNOGRAPHY:
 Social scientists spend a considerable time observing and analyzing how people
actually work.
 People do not have to explain or articulate their work.
 Social and organizational factors of importance may be observed.
 Ethnographic studies have shown that work is usually richer and more complex
than suggested by simple system models.

Focused ethnography:
 Developed in a project studying the air traffic control process Combines
ethnography with prototyping
 Prototype development results in unanswered questions which focus the
ethnographic analysis.
 The problem with ethnography is that it studies existing practices which may have
some historical basis which is no longer relevant.

Ethnography and prototyping

Figure 2.11

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 63

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Scope of ethnography:
 Requirements that are derived from the way that people actually work rather than
the way I which process definitions suggest that they ought to work.
 Requirements that are derived from cooperation and awareness of other people’s
activities.

REQUIREMENTS VALIDATION
 Concerned with demonstrating that the requirements define the system that the
customer really wants.
 Requirements error costs are high so validation is very important
 Fixing a requirements error after delivery may cost up to 100 times the cost of
fixing an implementation error.

Requirements checking:
 Validity: Does the system provide the functions which best support the customer’s
needs?
 Consistency: Are there any requirements conflicts?
 Completeness: Are all functions required by the customer included?
 Realism: Can the requirements be implemented given available budget and
technology
 Verifiability: Can the requirements be checked?

Requirements validation techniques

Requirements reviews
 Systematic manual analysis of the requirements.

Prototyping
 Using an executable model of the system to check requirements.

Test-case generation
 Developing tests for requirements to check testability.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 64

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Requirements reviews:
 Regular reviews should be held while the requirements definition is being
formulated.
 Both client and contractor staff should be involved in reviews.
 Reviews may be formal (with completed documents) or informal. Good
communications between developers, customers and users can resolve problems at
an early stage.

Review checks:
 Verifiability: Is the requirement realistically testable?
 Comprehensibility: Is the requirement properly understood?
 Traceability: Is the origin of the requirement clearly stated?
 Adaptability: Can the requirement be changed without a large impact on other
requirements?

REQUIREMENTS MANAGEMENT
 Requirements management is the process of managing changing requirements
during the requirements engineering process and system development.
 Requirements are inevitably incomplete and inconsistent
o New requirements emerge during the process as business needs change and a
better understanding of the system is developed;
o Different viewpoints have different requirements and these are often
contradictory.

Requirements change
 The priority of requirements from different viewpoints changes during the
development process.
 System customers may specify requirements from a business perspective that
conflict with end-user requirements.
 The business and technical environment of the system changes during its
development.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 65

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Requirements evolution:
Enduring and volatile requirements:

Figure 2.11

Enduring requirements: Stable requirements derived from the core activity of the
customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be
derived from domain models
Volatile requirements: Requirements which change during development or when the
system is in use. In a hospital, requirements derived from health-care policy .

Requirements classification: Requirements management planning:

During the requirements engineering process, you have to plan:
 Requirements identification
How requirements are individually identified;
 A change management process
The process followed when analysing a requirements change;
 Traceability policies
The amount of information about requirements relationships that is maintained;
 Traceability:
Traceability is concerned with the relationships between requirements, their sources
and the system design.
 Source traceability
Links from requirements to stakeholders who proposed these requirements;
 Requirements traceability
Links between dependent requirements;
 Design traceability - Links from the requirements to the design;

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 66

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

CASE tool support:

Requirements storage
 Requirements should be managed in a secure, managed data store.
Change management
 The process of change management is a workflow process whose stages can be
defined and information flow between these stages partially automated.
Traceability management
 Automated retrieval of the links between requirements.

Requirements change management:

Should apply to all proposed changes to the requirements.
 Problem analysis. Discuss requirements problem and propose change;
 Change analysis and costing. Assess effects of change on other requirements;
 Change implementation. Modify requirements document and other documents to
reflect change.

Change management:

Figure 2.12

SYSTEM MODELLING
System modelling helps the analyst to understand the functionality of the system
models are used to communicate with customers.

Different models present the system from different perspectives

 External (or Context) perspective - Show the system’s context or environment;
 Behavioural perspective - Show the behaviour of the system;
 Structural perspective - Show the system or data architecture.

Model types
Data processing model showing how the data is processed at different stages.
Composition model the system’s reaction to events.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 67

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

CONTEXT MODELS:
 Context models are used to illustrate the operational context of a system - they
show what lies outside the system boundaries.
 Social and organisational concerns may affect the decision on where to position
system boundaries.
 Ideally, the boundaries between the system and its environment are identified
clearly. Various models can be used for context modeling:

Very simple, high-level architectural models

 Show the system and its connections with environmental components High-level
process models
 Indicate main process activities High-level data-flow diagrams
 Depict data transformations and data transfers
 Architectural models show the system and its relationship with other systems.

The context of an ATM system:

Figure 2.13

Process models:
 Process models show the overall process and the processes that are supported by
the system.
 Data flow models may be used to show the processes and the flow of information
from one process to another.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 68

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

BEHAVIOURAL MODELS:
 Behavioral models are used to describe the overall behavior of a system. Two
types of behavioral model are:
 Data processing models that show how data is processed as it moves through the
system;
 State machine models that show the systems response to events.
 These models show different perspectives so both of them are required to describe
the system’s behavior.

Data-processing models:
 Data flow diagrams (DFDs) may be used to model the system’s data processing.
 These show the processing steps as data flows through a system.
 DFDs are an intrinsic part of many analysis methods.
 Simple and intuitive notation that customers can understand.
 Show end-to-end processing of data.

Order processing DFD:

Figure 2.14

Data flow diagrams:

 DFDs model the system from a functional perspective.
 Tracking and documenting how the data associated with a process is helpful to
develop an overall understanding of the system.
 Data flow diagrams may also be used in showing the data exchange between a
system and other systems in its environment.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 69

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

State machine models:

 These model the behaviour of the system in response to external and internal
events.
 They show the system’s responses to stimuli so are often used for modelling real-
time systems.
 State machine models show system states as nodes and events as arcs between
these nodes. When an event occurs, the system moves from one state to another.
 Statecharts are an integral part of the UML and are used to represent state machine
models.

Statecharts:
 Allow the decomposition of a model into sub-models (see following slide).
 A brief description of the actions is included following the ‘do’ in each state.
 Can be complemented by tables describing the states and the stimuli.

Microwave oven model:

Figure 2.15

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 70

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Microwave oven state description:

State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is set to the user’s input value. The display shows the
cooking time selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on. Display
shows ‘Not ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows
‘Ready to cook’.

Operation Oven in operation. Interior oven light is on. Display shows the timer
countdown. On completion of cooking, the buzzer is sounded for 5 seconds. Oven
light is on. Display shows ‘Cooking complete’ while buzzer is sounding.

Microwave oven stimuli:

Stimulus Description
Half power The user has pressed the half power button
Full power. The user has pressed the full power button
Timer. The user has pressed one of the timer buttons
Number The user has pressed a numeric key
Door open. The oven door switch is not closed
Door closed The oven door switch is closed
Start The user has pressed the start button
Cancel The user has pressed the cancel button

DATA MODELS:
 Used to describe the logical structure of data processed by the system.
 An entity-relation-attribute model sets out the entities in the system, the
relationships between these entities and the entity attributes
 Widely used in database design. Can readily be implemented using relational
databases.
 No specific notation provided in the UML but objects and associations can be
used.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 71

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Data dictionaries
 Data dictionaries are lists of all of the names used in the system models.
 Descriptions of the entities, relationships and attributes are also included.

Advantages
 Support name management and avoid duplication;
 Store of organizational knowledge linking analysis, design and implementation;
 Many Case workbenches support data dictionaries.

OBJECT MODELS:
 Object models describe the system in terms of object classes and their associations.
 An object class is an abstraction over a set of objects with common attributes and
the services (operations) provided by each object.
 Various object models may be produced
 Inheritance models;
 Aggregation models;
 Interaction models.
 Natural ways of reflecting the real-world entities manipulated by the system
 More abstract entities are more difficult to model using this approach
 Object class identification is recognized as a difficult process
 Requiring a deep understanding of the application domain
 Object classes reflecting domain entities are reusable across system.

Types of Relationships in OO
1. “is a” - inheritance
2. “has a” - encapsulation (aggregation) 3.“association” - anything else

Inheritance models:
 Organise the domain object classes into a hierarchy.
 Classes at the top of the hierarchy reflect the common features of all classes.
 Object classes inherit their attributes and services from one or more super-classes.
these may then be specialized as necessary.
 Class hierarchy design can be a difficult process if duplication in different
branches is to be avoided.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 72

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Object models and the UML:

 The UML is a standard representation devised by the developers of widely used
object- oriented analysis and design methods.
 It has become an effective standard for object-oriented modeling.
 Notation
o Object classes are rectangles with the name at the top, attributes in the middle
section and operations in the bottom section;
o Relationships between object classes (known as associations) are shown as
lines linking objects;
o Inheritance is referred to as generalization and is shown ‘upwards’ rather than
‘downwards’ in a hierarchy.

Library class hierarchy:

User class hierarchy:

Figure 2.16

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 73

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Multiple inheritance:

Figure 2.17

 Rather than inheriting the attributes and services from a single parent class, a
system which supports multiple inheritance allows object classes to inherit from
several super- classes.
 This can lead to semantic conflicts where attributes/services with the same name
in different super-classes have different semantics.
 Multiple inheritance makes class hierarchy reorganization more complex.

Multiple inheritance

Figure 2.18

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 74

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Object aggregation:
 An aggregation model shows how classes that are collections are composed of
other classes.
 Aggregation models are similar to the part-of relationship in semantic data
models.

Object
Object aggregation

Figure 2.19

Object behavior modeling

 A behavioral model shows the interactions between objects to produce some
particular system behavior that is specified as a use-case.
 Sequence diagrams (or collaboration diagrams) in the UML are used to model
interaction between objects.

STRUCTURED METHODS:
 Structured methods incorporate system modelling as an inherent part of the
method.
 Methods define a set of models, a process for deriving these models and rules and
guidelines that should apply to the models.
 CASE tools support system modelling as part of a structured method.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 75

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Method weaknesses:
 They do not model non-functional system requirements.
 They do not usually include information about whether a method is appropriate for
a given problem.
 The may produce too much documentation.
 The system models are sometimes too detailed and difficult for users to
understand.

CASE workbenches:
 A coherent set of tools that is designed to support related software process
activities such as analysis, design or testing.
 Analysis and design workbenches support system modeling during both
requirements engineering and system design.
 These workbenches may support a specific design method or may provide support
for a creating several different types of system model.

An analysis and design workbench

Figure 2.20

Analysis workbench components:

 Diagram editors
 Model analysis and checking tools
 Repository and associated query language
 Data dictionary
 Report definition and generation tools
 Forms definition tools

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 76

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 Import/export translators
 Code generation tool

UML Diagrams
UML (Unified Modeling Language) is a standard language for specifying,
visualizing, constructing, and documenting the artifacts of software systems. UML
was created by the Object Management Group (OMG) and UML 1.0 specification
draft was proposed to the OMG in January 1997. It was initially started to capture the
behavior of complex software and non-software system and now it has become an
OMG standard. This tutorial gives a complete understanding on UML.

UML is a standard language for specifying, visualizing, constructing, and

documenting the artifacts of software systems.

UML was created by the Object Management Group (OMG) and UML 1.0
specification draft was proposed to the OMG in January 1997.

OMG is continuously making efforts to create a truly industry standard.

 UML stands for Unified Modeling Language.
 UML is different from the other common programming languages such as C++,
Java, COBOL, etc.
 UML is a pictorial language used to make software blueprints.
 UML can be described as a general purpose visual modeling language to
visualize, specify, construct, and document software system.
 Although UML is generally used to model software systems, it is not limited
within this boundary. It is also used to model non-software systems as well. For
example, the process flow in a manufacturing unit, etc.

UML is not a programming language but tools can be used to generate code in
various languages using UML diagrams. UML has a direct relation with object
oriented analysis and design. After some standardization, UML has become an OMG
standard.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 77

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Goals of UML
A picture is worth a thousand words, this idiom absolutely fits describing
UML. Object-oriented concepts were introduced much earlier than UML. At that
point of time, there were no standard methodologies to organize and consolidate the
object-oriented development. It was then that UML came into picture.

There are a number of goals for developing UML but the most important is to
define some general purpose modeling language, which all modelers can use and it
also needs to be made simple to understand and use.

UML diagrams are not only made for developers but also for business users,
common people, and anybody interested to understand the system. The system can be
a software or non-software system. Thus it must be clear that UML is not a
development method rather it accompanies with processes to make it a successful
system.

In conclusion, the goal of UML can be defined as a simple modeling

mechanism to model all possible practical systems in today’s complex environment.

A Conceptual Model of UML

To understand the conceptual model of UML, first we need to clarify what is a
conceptual model? and why a conceptual model is required?
 A conceptual model can be defined as a model which is made of concepts and
their relationships.
 A conceptual model is the first step before drawing a UML diagram. It helps to
understand the entities in the real world and how they interact with each other.

As UML describes the real-time systems, it is very important to make a

conceptual model and then proceed gradually. The conceptual model of UML can be
mastered by learning the following three major elements −
 UML building blocks
 Rules to connect the building blocks
 Common mechanisms of UML

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 78

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Object-Oriented Concepts
UML can be described as the successor of object-oriented (OO) analysis and design.

An object contains both data and methods that control the data. The data represents
the state of the object. A class describes an object and they also form a hierarchy to
model the real-world system. The hierarchy is represented as inheritance and the
classes can also be associated in different ways as per the requirement.

Objects are the real-world entities that exist around us and the basic concepts such as
abstraction, encapsulation, inheritance, and polymorphism all can be represented
using UML

UML is powerful enough to represent all the concepts that exist in object-oriented
analysis and design. UML diagrams are representation of object-oriented concepts
only. Thus, before learning UML, it becomes important to understand OO concept in
detail.

Following are some fundamental concepts of the object-oriented world −

 Objects − Objects represent an entity and the basic building block.
 Class − Class is the blue print of an object.
 Abstraction − Abstraction represents the behavior of an real world entity.
 Encapsulation − Encapsulation is the mechanism of binding the data together and
hiding them from the outside world.
 Inheritance − Inheritance is the mechanism of making new classes from existing
ones.
 Polymorphism − It defines the mechanism to exists in different forms.

OO Analysis and Design

OO can be defined as an investigation and to be more specific, it is the
investigation of objects. Design means collaboration of identified objects.

Thus, it is important to understand the OO analysis and design concepts. The

most important purpose of OO analysis is to identify objects of a system to be
designed. This analysis is also done for an existing system. Now an efficient analysis

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 79

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

is only possible when we are able to start thinking in a way where objects can be
identified. After identifying the objects, their relationships are identified and finally
the design is produced.

The purpose of OO analysis and design can described as −

 Identifying the objects of a system.
 Identifying their relationships.
 Making a design, which can be converted to executables using OO languages.

There are three basic steps where the OO concepts are applied and implemented. The
steps can be defined as
OO Analysis → OO Design → OO implementation using OO languages

The above three points can be described in detail as −

 During OO analysis, the most important purpose is to identify objects and
describe them in a proper way. If these objects are identified efficiently, then the
next job of design is easy. The objects should be identified with responsibilities.
Responsibilities are the functions performed by the object. Each and every object
has some type of responsibilities to be performed. When these responsibilities are
collaborated, the purpose of the system is fulfilled.
 The second phase is OO design. During this phase, emphasis is placed on the
requirements and their fulfilment. In this stage, the objects are collaborated
according to their intended association. After the association is complete, the
design is also complete.
 The third phase is OO implementation. In this phase, the design is implemented
using OO languages such as Java, C++, etc.

Role of UML in OO Design

UML is a modeling language used to model software and non-software
systems. Although UML is used for non-software systems, the emphasis is on
modeling OO software applications. Most of the UML diagrams discussed so far are
used to model different aspects such as static, dynamic, etc. Now whatever be the
aspect, the artifacts are nothing but objects.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 80

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

If we look into class diagram, object diagram, collaboration diagram,

interaction diagrams all would basically be designed based on the objects.

Hence, the relation between OO design and UML is very important to

understand. The OO design is transformed into UML diagrams according to the
requirement. Before understanding the UML in detail, the OO concept should be
learned properly. Once the OO analysis and design is done, the next step is very easy.
The input from OO analysis and design is the input to UML diagrams.

As UML describes the real-time systems, it is very important to make a

conceptual model and then proceed gradually. The conceptual model of UML can be
mastered by learning the following three major elements −
 UML building blocks
 Rules to connect the building blocks
 Common mechanisms of UML

This chapter describes all the UML building blocks. The building blocks of UML can
be defined as −
 Things
 Relationships
 Diagrams

Things
Things are the most important building blocks of UML. Things can be −
 Structural
 Behavioral
 Grouping
 Annotational

Structural Things
Structural things define the static part of the model. They represent the physical and
conceptual elements. Following are the brief descriptions of the structural things.
Class − Class represents a set of objects having similar responsibilities.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 81

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Interface − Interface defines a set of operations, which specify the responsibility of a

class.

Collaboration −Collaboration defines an interaction between elements.

Use case −Use case represents a set of actions performed by a system for a specific
goal.

Component −Component describes the physical part of a system.

Node − A node can be defined as a physical element that exists at run time.

BEHAVIORAL THINGS
A behavioral thing consists of the dynamic parts of UML models. Following are the
behavioral things −

Interaction − Interaction is defined as a behavior that consists of a group of messages

exchanged among elements to accomplish a specific task.

State machine − State machine is useful when the state of an object in its life cycle is
important. It defines the sequence of states an object goes through in response to
events. Events are external factors responsible for state change

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 82

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

GROUPING THINGS
Grouping things can be defined as a mechanism to group elements of a UML model
together. There is only one grouping thing available −

Package − Package is the only one grouping thing available for gathering structural
and behavioral things.

Annotational Things
Annotational things can be defined as a mechanism to capture remarks, descriptions,
and comments of UML model elements. Note - It is the only one Annotational thing
available. A note is used to render comments, constraints, etc. of an UML element.

Relationship
Relationship is another most important building block of UML. It shows how the
elements are associated with each other and this association describes the
functionality of an application.
There are four kinds of relationships available.

Dependency
Dependency is a relationship between two things in which change in one element also
affects the other.

Association
Association is basically a set of links that connects the elements of a UML model. It
also describes how many objects are taking part in that relationship.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 83

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Generalization
Generalization can be defined as a relationship which connects a specialized element
with a generalized element. It basically describes the inheritance relationship in the
world of objects.

Realization
Realization can be defined as a relationship in which two elements are connected. One
element describes some responsibility, which is not implemented and the other one
implements them. This relationship exists in case of interfaces.

Types of UML Diagrams

UML diagrams are the ultimate output of the entire discussion. All the elements,
relationships are used to make a complete UML diagram and the diagram represents a
system.
The visual effect of the UML diagram is the most important part of the entire process.
All the other elements are used to make it complete.
UML includes the following nine diagrams, the details of which are described in the
subsequent chapters.
 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 Statechart diagram
 Deployment diagram
 Component diagram

Any real-world system is used by different users. The users can be developers, testers,
business people, analysts, and many more. Hence, before designing a system, the

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 84

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

architecture is made with different perspectives in mind. The most important part is to
visualize the system from the perspective of different viewers. The better we
understand the better we can build the system.

UML plays an important role in defining different perspectives of a system. These

perspectives are −
 Design
 Implementation
 Process
 Deployment

The center is the Use Case view which connects all these four. A Use Case represents
the functionality of the system. Hence, other perspectives are connected with use case.

Design of a system consists of classes, interfaces, and collaboration. UML provides

class diagram, object diagram to support this.

Implementation defines the components assembled together to make a complete

physical system. UML component diagram is used to support the implementation
perspective.

Process defines the flow of the system. Hence, the same elements as used in Design
are also used to support this perspective.

Deployment represents the physical nodes of the system that forms the hardware.
UML deployment diagram is used to support this perspective.

It is very important to distinguish between the UML model. Different diagrams are
used for different types of UML modeling. There are three important types of UML
modeling.

Structural Modeling
Structural modeling captures the static features of a system. They consist of the
following −
 Classes diagrams
 Objects diagrams

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 85

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 Deployment diagrams
 Package diagrams
 Composite structure diagram
 Component diagram
Structural model represents the framework for the system and this framework is the
place where all other components exist. Hence, the class diagram, component diagram
and deployment diagrams are part of structural modeling. They all represent the
elements and the mechanism to assemble them.

The structural model never describes the dynamic behavior of the system. Class
diagram is the most widely used structural diagram.

Behavioral Modeling
Behavioral model describes the interaction in the system. It represents the interaction
among the structural diagrams. Behavioral modeling shows the dynamic nature of the
system. They consist of the following −
 Activity diagrams
 Interaction diagrams
 Use case diagrams
All the above show the dynamic sequence of flow in a system.

Architectural Modeling
Architectural model represents the overall framework of the system. It
contains both structural and behavioral elements of the system. Architectural model
can be defined as the blueprint of the entire system. Package diagram comes under
architectural modeling.

UML is popular for its diagrammatic notations. We all know that UML is for
visualizing, specifying, constructing and documenting the components of software
and non-software systems. Hence, visualization is the most important part which
needs to be understood and remembered.

UML notations are the most important elements in modeling. Efficient and
appropriate use of notations is very important for making a complete and meaningful
model. The model is useless, unless its purpose is depicted properly.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 86

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Hence, learning notations should be emphasized from the very beginning.

Different notations are available for things and relationships. UML diagrams are made
using the notations of things and relationships. Extensibility is another important
feature which makes UML more powerful and flexible.

Structural Things
Graphical notations used in structural things are most widely used in UML.
These are considered as the nouns of UML models. Following are the list of structural
things.
 Classes
 Object
 Interface
 Collaboration
 Use case
 Active classes
 Components
 Nodes

Class Notation
UML class is represented by the following figure. The diagram is divided into four
parts.
 The top section is used to name the class.
 The second one is used to show the attributes of the class.
 The third section is used to describe the operations performed by the class.
 The fourth section is optional to show any additional components.

Figure 2.21

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 87

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Classes are used to represent objects. Objects can be anything having

properties and responsibility.

Object Notation
The object is represented in the same way as the class. The only difference is
the name which is underlined as shown in the following figure.

Figure 2.22

As the object is an actual implementation of a class, which is known as the

instance of a class. Hence, it has the same usage as the class.

Interface Notation
Interface is represented by a circle as shown in the following figure. It has a
name which is generally written below the circle.

Figure 2.23

Interface is used to describe the functionality without implementation.

Interface is just like a template where you define different functions, not the
implementation. When a class implements the interface, it also implements the
functionality as per requirement.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 88

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Collaboration Notation
Collaboration is represented by a dotted eclipse as shown in the following
figure. It has a name written inside the eclipse.

Figure 2.24

Collaboration represents responsibilities. Generally, responsibilities are in a group.

Use Case Notation

Use case is represented as an eclipse with a name inside it. It may contain
additional responsibilities.

Figure 2.25

Use case is used to capture high level functionalities of a system.

Actor Notation
An actor can be defined as some internal or external entity that interacts with
the system.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 89

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 2.26
An actor is used in a use case diagram to describe the internal or external entities.

Initial State Notation

Initial state is defined to show the start of a process. This notation is used in
almost all diagrams.

Figure 2.27

The usage of Initial State Notation is to show the starting point of a process.

Final State Notation

Final state is used to show the end of a process. This notation is also used in
almost all diagrams to describe the end.

Figure 2.28

The usage of Final State Notation is to show the termination point of a process.

Active Class Notation

Active class looks similar to a class with a solid border. Active class is
generally used to describe the concurrent behavior of a system.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 90

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 2.29

Active class is used to represent the concurrency in a system.

Component Notation
A component in UML is shown in the following figure with a name inside.
Additional elements can be added wherever required.

Figure 2.30

Component is used to represent any part of a system for which UML diagrams are
made.

Node Notation
A node in UML is represented by a square box as shown in the following
figure with a name. A node represents the physical component of the system.

Figure 2.31

Node is used to represent the physical part of a system such as the server, network,
etc.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 91

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Behavioral Things
Dynamic parts are one of the most important elements in UML. UML has a set
of powerful features to represent the dynamic part of software and non-software
systems. These features include interactions and state machines.

Interactions can be of two types −

 Sequential (Represented by sequence diagram)
 Collaborative (Represented by collaboration diagram)

Interaction Notation
Interaction is basically a message exchange between two UML components.
The following diagram represents different notations used in an interaction

Figure 2.32

Interaction is used to represent the communication among the components of a

system.

State Machine Notation

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 92

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

State machine describes the different states of a component in its life cycle.
The notations are described in the following diagram.

Figure 2.33

State machine is used to describe different states of a system component. The

state can be active, idle, or any other depending upon the situation.

Grouping Things
Organizing the UML models is one of the most important aspects of the
design. In UML, there is only one element available for grouping and that is package.

Package Notation
Package notation is shown in the following figure and is used to wrap the
components of a system.

Figure 2.34

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 93

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Annotational Things
In any diagram, explanation of different elements and their functionalities are
very important. Hence, UML has notes notation to support this requirement.

Note Notation
This notation is shown in the following figure. These notations are used to
provide necessary information of a system.

Figure 2.35

Relationships
A model is not complete unless the relationships between elements are
described properly. The Relationship gives a proper meaning to a UML model.
Following are the different types of relationships available in UML.
 Dependency
 Association
 Generalization
 Extensibility

Dependency Notation
Dependency is an important aspect in UML elements. It describes the
dependent elements and the direction of dependency.

Dependency is represented by a dotted arrow as shown in the following figure.

The arrow head represents the independent element and the other end represents the
dependent element.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 94

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 2.36

Dependency is used to represent the dependency between two elements of a system

Association Notation
Association describes how the elements in a UML diagram are associated. In
simple words, it describes how many elements are taking part in an interaction.

Association is represented by a dotted line with (without) arrows on both

sides. The two ends represent two associated elements as shown in the following
figure. The multiplicity is also mentioned at the ends (1, *, etc.) to show how many
objects are associated.

Figure 2.37

Association is used to represent the relationship between two elements of a system.

Generalization Notation
Generalization describes the inheritance relationship of the object-oriented
world. It is a parent and child relationship.

Generalization is represented by an arrow with a hollow arrow head as shown

in the following figure. One end represents the parent element and the other end
represents the child element.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 95

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 2.38

Generalization is used to describe parent-child relationship of two elements of a system.

Extensibility Notation
All the languages (programming or modeling) have some mechanism to
extend its capabilities such as syntax, semantics, etc. UML also has the following
mechanisms to provide extensibility features.
 Stereotypes (Represents new elements)
 Tagged values (Represents new attributes)
 Constraints (Represents the boundaries)

Figure 2.39

Extensibility notations are used to enhance the power of the language. It is

basically additional elements used to represent some extra behavior of the system.
These extra behaviors are not covered by the standard available notations.

How to Draw a Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of
software applications. It is very important to learn the drawing procedure of class
diagram.

Class diagrams have a lot of properties to consider while drawing but here the
diagram will be considered from a top level view.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 96

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Class diagram is basically a graphical representation of the static view of the

system and represents different aspects of the application. A collection of class
diagrams represent the whole system.

The following points should be remembered while drawing a class diagram –

 The name of the class diagram should be meaningful to describe the aspect of the
system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly identified
 For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. At the end
of the drawing it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain
paper and reworked as many times as possible to make it correct.

The following diagram is an example of an Order System of an application. It

describes a particular aspect of the entire application.

 First of all, Order and Customer are identified as the two elements of the system.
They have a one-to-many relationship because a customer can have multiple
orders.
 Order class is an abstract class and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In addition,
they have additional functions like dispatch () and receive ().

The following class diagram has been drawn considering all the points
mentioned above.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 97

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 2.40

Where to Use Class Diagrams?

Class diagram is a static diagram and it is used to model the static view of a
system. The static view describes the vocabulary of the system.

Class diagram is also considered as the foundation for component and

deployment diagrams. Class diagrams are not only used to visualize the static view of
the system but they are also used to construct the executable code for forward and
reverse engineering of any system.

Generally, UML diagrams are not directly mapped with any object-oriented
programming languages but the class diagram is an exception.

Class diagram clearly shows the mapping with object-oriented languages such
as Java, C++, etc. From practical experience, class diagram is generally used for
construction purpose.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 98

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

In a nutshell it can be said, class diagrams are used for −

 Describing the static view of the system.
 Showing the collaboration among the elements of the static view.
 Describing the functionalities performed by the system.
 Construction of software applications using object oriented languages.

Object diagrams are derived from class diagrams so object diagrams are
dependent upon class diagrams.

Object diagrams represent an instance of a class diagram. The basic concepts

are similar for class diagrams and object diagrams. Object diagrams also represent the
static view of a system but this static view is a snapshot of the system at a particular
moment.

Object diagrams are used to render a set of objects and their relationships as an
instance.

Purpose of Object Diagrams

The purpose of a diagram should be understood clearly to implement it
practically. The purposes of object diagrams are similar to class diagrams.

The difference is that a class diagram represents an abstract model consisting

of classes and their relationships. However, an object diagram represents an instance
at a particular moment, which is concrete in nature.
It means the object diagram is closer to the actual system behavior. The
purpose is to capture the static view of a system at a particular moment.

The purpose of the object diagram can be summarized as −

 Forward and reverse engineering.
 Object relationships of a system
 Static view of an interaction.
 Understand object behaviour and their relationship from practical perspective

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 99

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

How to Draw an Object Diagram?

We have already discussed that an object diagram is an instance of a class
diagram. It implies that an object diagram consists of instances of things used in a
class diagram. So both diagrams are made of same basic elements but in different
form. In class diagram elements are in abstract form to represent the blue print and in
object diagram the elements are in concrete form to represent the real world object.

To capture a particular system, numbers of class diagrams are limited.

However, if we consider object diagrams then we can have unlimited number of
instances, which are unique in nature. Only those instances are considered, which
have an impact on the system.

From the above discussion, it is clear that a single object diagram cannot
capture all the necessary instances or rather cannot specify all the objects of a system.
Hence, the solution is −
 First, analyze the system and decide which instances have important data and
association.
 Second, consider only those instances, which will cover the functionality.
 Third, make some optimization as the number of instances are unlimited.

Before drawing an object diagram, the following things should be remembered

and understood clearly −
 Object diagrams consist of objects.
 The link in object diagram is used to connect objects.
 Objects and links are the two elements used to construct an object diagram.

After this, the following things are to be decided before starting the
construction of the diagram −
 The object diagram should have a meaningful name to indicate its purpose.
 The most important elements are to be identified.
 The association among objects should be clarified.
 Values of different elements need to be captured to include in the object diagram.
 Add proper notes at points where more clarity is required.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 100

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The following diagram is an example of an object diagram. It represents the

Order management system which we have discussed in the chapter Class Diagram.
The following diagram is an instance of the system at a particular time of purchase. It
has the following objects.
 Customer
 Order
 Special Order
 Normal Order

Now the customer object (C) is associated with three order objects (O1, O2,
and O3). These order objects are associated with special order and normal order
objects (S1, S2, and N1). The customer has the following three orders with different
numbers (12, 32 and 40) for the particular time considered.

The customer can increase the number of orders in future and in that scenario
the object diagram will reflect that. If order, special order, and normal order objects
are observed then you will find that they have some values. For orders, the values are
12, 32, and 40 which implies that the objects have these values for a particular
moment (here the particular time when the purchase is made is considered as the
moment) when the instance is captured

The same is true for special order and normal order objects which have
number of orders as 20, 30, and 60. If a different time of purchase is considered, then
these values will change accordingly. The following object diagram has been drawn
considering all the points mentioned above

Figure 2.41

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 101

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Where to Use Object Diagrams?

Object diagrams can be imagined as the snapshot of a running system at a
particular moment. Let us consider an example of a running train. Now, if you take a
snap of the running train then you will find a static picture of it having the following −
 A particular state which is running.
 A particular number of passengers. which will change if the snap is taken in a
different time

Here, we can imagine the snap of the running train is an object having the
above values. And this is true for any real-life simple or complex system.
In a nutshell, it can be said that object diagrams are used for −
 Making the prototype of a system.
 Reverse engineering.
 Modeling complex data structures.
 Understanding the system from practical perspective.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 102

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT - III
DESIGN ENGINEERING

Design engineering encompasses the set of principals, concepts, and

practices that lead to the development of a high- quality system or product.
Design principles establish an overriding philosophy that guides the designer in the
work. Design concepts must be understood before the mechanics of design practice
are applied and Design practice itself leads to the creation of various representations
of the software that serve as a guide for the construction activity that follows.

What is design:
Design is what virtually every engineer wants to do. It is the place where
creativity rules – customer’s requirements, business needs, and technical
considerations all come together in the formulation of a product or a system. Design
creates a representation or model of the software, but unlike the analysis model, the
design model provides detail about software data structures, architecture, interfaces,
and components that are necessary to implement the system.

Why is it important:
Design allows a software engineer 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.

The goal of design engineering is to produce a model or representation that

exhibits firmness, commodity, and delight. To accomplish this, a designer must
practice diversification and then convergence. Another goal of software design is to
derive an architectural rendering of a system. The rendering serves as a framework
from which more detailed design activities are conducted.

DESIGN PROCESS AND DESIGN QUALITY:

Software design is an iterative process through which requirements are
translated into a “blueprint” for constructing the software.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 103

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Goals of design:
McGlaughlin suggests 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 analysis model, and it must accommodate all of the
implicit requirements desired by the customer. 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 we must establish
technical criteria for good design. These are the following guidelines:
 A design should exhibit an architecture that has been created using recognizable
architectural styles or patterns is composed of components that exhibit good design
characteristics and can be implemented in an evolutionary fashion, thereby
facilitating implementation and testing.
 A design should be modular; that is, the software should be logically partitioned
into elements or subsystems. A design should contain distinct representation of
data, architecture, interfaces and components.
 A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns.
 A design should lead to components that exhibit independent functional
characteristic
 A design should lead to interface that reduce the complexity of connections
between components and with the external environment.
 A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis.

These design guidelines are not achieved by chance. Design engineering

encourages good design through the application of fundamental design principles,
systematic methodology, and thorough review.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 104

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Quality attributes:
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, and the mean – time –to- failure (MTTF), the ability to
recover from failure, and the predictability of the program.

Performance is measured by 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
Not every software quality attribute is weighted equally as the software design is
developed.

DESIGN CONCEPTS:
M.A Jackson once said:”The beginning of wisdom for a software engineer is
to recognize the difference between getting a program to work, and getting it right.”
Fundamental software design concepts provide the necessary framework for “getting
it right.”

Abstraction: Many levels of abstraction are there. 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.

A procedural abstraction refers to a sequence of instructions that have a

specific and limited function. The name of procedural abstraction implies these
functions, but specific details are suppressed.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 105

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

A data abstraction is a named collection of data that describes a data object.

In the context of the procedural abstraction open, we can define a data abstraction
called door. Like any data object, the data abstraction for door would encompass a
set of attributes that describe the door (e.g., door type, swing operation, opening
mechanism, weight, dimensions).

It follows that the procedural abstraction open would make use of information
contained in the attributes of the data abstraction door.

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. The rendering serves as a framework from which
more detailed design activities are conducted.

The architectural design can be represented using one or more of a number of

different models.
Structured models represent architecture as an organized collection of
program components.

Framework models increase the level of design abstraction by attempting to

identify repeatable architectural design frameworks that are encountered in similar
types of applications.

Dynamic models address the behavioral aspects of the program architecture,

indicating how the structure or system configuration may change as a function
external events.

Process models focus on the design of the business or technical process that
the system must accommodate.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 106

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Functional models can be used to represent the functional hierarchy of a

system.

Patterns:
Brad Appleton defines a design pattern in the following manner: “a pattern is
a named nugget of inside which conveys that essence of a proven solution to a
recurring problem within a certain context amidst competing concerns.” Stated in
another way, a design pattern describes a design structure that solves a particular
design 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 Whether the pattern is capable to the current work, Whether the
pattern can serve as a guide for developing a similar, but functionally or structurally
different pattern.

IV. MODULARITY:
Software architecture and design patterns embody modularity; 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”. Monolithic software cannot be easily grasped by a
software engineer. The number of control paths, span of reference, number of
variables, and overall complexity would make understanding close to impossible. The
“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 modularity and software. If we
subdivide software indefinitely, the effort required to develop it will become
negligibly small. The effort 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 associated with

integrating the modules also grow. Under modularity or over modularity should be

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 107

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

avoided. We modularize a design so that development can be more easily planned;

software increment 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.

V. INFORMATION HIDING:
The principle of information hiding suggests that modules be “characterized
by design decision that hides from all others.” Modules should be specified and
designed so that information 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
entities that make up the software. Hiding defines and enforces access constraints to
both procedural detail within a module and local data structure used by 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 procedure are hidden from other parts
of the software, inadvertent errors introduced during modification are less likely to
propagate to other locations within software.

VI. FUNCTIONAL INDEPENDENCE:

The concept of functional independence is a direct outgrowth of modularity
and the concepts of abstraction and information hiding. Functional independence is
achieved by developing modules with “single minded” function and an “aversion” to
excessive interaction with other modules. Stated another way, we want to design
software so that each module addresses a specific sub function of requirements and
has a simple interface when viewed from other parts of the program structure.
Software with effective modularity, that is, independent modules, is easier to develop
because function may be compartmentalized and interfaces are simplified.
Independent sign or code modifications 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

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 108

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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. Cohesion is a natural extension of the information
hiding. A cohesion module performs a single task, requiring little interaction with
other components in other parts of a program. Stated simply, a cohesive module
should do just one thing. 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, we strive for lowest possible
coupling.

VII. REFINEMENT:
Stepwise refinement is a top- down design strategy originally proposed by
Niklaus wirth. A program is development by successively refining levels of
procedural detail. A hierarchy is development by decomposing a macroscopic
statement of function in a step wise fashion until programming language statements
are reached. Refinement is actually a process of elaboration.

We begin with a statement of function that is defined at a high level of

abstraction. That is, the statement describes function or information conceptually but
provides no information about the internal workings of the function or the internal
structure of the data. Refinement causes the designer to elaborate on the original
statement, providing more and more detail as each successive refinement occurs.
Abstraction and refinement are complementary concepts. Abstraction enables a
designer to specify procedure and data and yet suppress low-level details.

Refinement helps the designer to reveal low-level details as design progresses.

Both concepts aid the designer in creating a complete design model as the design
evolves.

VIII. REFACTORING :
Refactoring is a reorganization technique that simplifies the design of a
component without changing its function or behavior. Fowler defines refactoring in
the following manner: “refactoring is the process of changing a software system in

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 109

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

such a way that it does not alter the external behavior of the code 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 designer may decide that the component should
be refactored into 3 separate components, each exhibiting high cohesion. The result
will be software that is easier to integrate, easier to test, and easier to maintain.

IX. DESIGN CLASSES:

The software team must define a set of design classes that Refine the analysis
classes by providing design detail that will enable the classes to be implemented, and
Create a new set of design classes that implement a software infrastructure to support
the design solution. Five different types of design classes, each representing a
different layer of the design architecture are suggested.

User interface classes: define all abstractions that are necessary for human computer
interaction. In many cases, HCL occurs within the context of a metaphor 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 defined
earlier. The classes identify the attributes and services 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 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. As the design model evolves, the software team must develop a
complete set of attributes and operations for each design class. The level of
abstraction is reduced as each analysis class is transformed into a design
representation. Each design class be reviewed to ensure that it is “well-formed.”

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 110

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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 to exist for the class.
Sufficiency ensures that the design class contains only those methods that are
sufficient to achieve the intent of the class, no more and no less.

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 classes in other subsystems. This restriction, called
the law of Demeter, suggests that a method should only sent messages to methods in
neighboring classes.

THE DESIGN MODEL:

The design model can be viewed into different dimensions. The process
dimension indicates the evolution of the design model as design tasks are executed as
a 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.

The elements of the design model use many of the same UML diagrams that
were used in the analysis model. The difference is that these diagrams are refined and
elaborated as a path of design; more implementation- specific detail is provided, and
architectural structure and style, components that reside within the architecture, and
the interface between the components and with the outside world are all emphasized.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 111

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 3.1 : Dimension of Design Model

It is important to mention however, that model elements noted along the horizontal
axis are not always developed in a sequential fashion. In most cases preliminary
architectural design sets the stage and is followed by interface design and component-
level design, which often occur in parallel. The deployment model us usually delayed
until the design has been fully developed.

Data design elements:

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 criterion of high-
quality applications.

At the application level, the translation of a data model into a database is

pivotal to achieving the business objectives of a system.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 112

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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.

Architectural design elements:

The architectural design for software is the equivalent to the floor plan of a
house. The architectural model is derived from three sources. Information about the
application domain for the software to build. Specific analysis model elements such as
data flow diagrams or analysis classes, their relationships and collaborations for the
problem at hand, and The availability of architectural patterns.

Interface design elements:

The interface design for software is the equivalent to a set of detailed
drawings for the doors, windows, and external utilities of a house. The interface
design elements for software tell how information flows into and out of the system
and how it is communicated among the components defined as part of the
architecture.

There are 3 important elements of interface design:

1. The user interface(UI);External interfaces to other systems, devices, networks, or
other produces or consumers of information; and Internal interfaces between
various design components.
2. These interface design elements allow the software to communicated externally
and enable internal communication and collaboration among the components that
populate the software architecture.
3. UI design is a major software engineering action.

The design of a UI 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). In general, the UI is a unique subsystem within the overall
application architecture.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 113

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The design of external interfaces requires definitive information about the

entity to which information is sent or received. The design of external interfaces
should incorporate error checking and appropriated security features.

UML defines an interface in the following manner:”an interface is a specifier

for the externally- visible operations of a class, component, or other classifier without
specification of internal structure.”
Interface Representation for Control Panel

Figure 3.2
Component-level design elements:
The component-level design for software is equivalent to a set of detailed
drawings. 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.

Sens orManagement
Sens or

Figure 3.3

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 114

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Deployment-level design elements:

Deployment-level design elements indicated how software functionality and
subsystems will be allocated within the physical computing environment that will
support the software

Figure 3.4 : Architectural Design

SOFTWARE ARCHITECTURE:
What Is Architecture?
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 a system. The architecture is a representation that enables a software
engineer to analyze the effectiveness of the design in meeting its stated requirements,
consider architectural alternatives at a stage when making design changes is still
relatively easy, reducing the risks associated with the construction of the software.
The design of software architecture considers two levels of the design pyramid data
design architectural design. Data design enables us to represent the data component of
the architecture. Architectural design focuses on the representation of the structure of
software components, their properties, and interactions.

Why Is Architecture Important?

Bass and his colleagues identify three key reasons that software architecture is
important:

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 115

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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”

DATA DESIGN:
The data design activity translates data objects as part of the analysis model
into data structures at the software component level and, when necessary, a database
architecture at the application level.

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 (derived as part of

requirements engineering) into a database is pivotal to achieving the business
objectives of a 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.

Data design at the Architectural Level:

The challenge for a business has been to extract useful information from this
data environment, particularly when the information desired is cross functional. To
solve this challenge, the business IT community has developed data mining
techniques, also called knowledge discovery in databases (KDD), that navigate
through existing databases in an attempt to extract appropriate business-level
information. An alternative solution, called a data warehouse, adds an additional
layer to the data architecture. a data warehouse is a large, independent database that

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 116

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

encompasses some, but not all, of the data that are stored in databases that serve the
set of applications required by a business.

Data design at the Component Level:

Data design at the component level focuses on the representation of data
structures that are directly accessed by one or more software components. The
following set of principles for data specification: The systematic analysis principles
applied to function and behavior should also be applied to data. All data structures
and the operations to be performed on each should be identified.

A data dictionary should be established and used to define both data and
program design. Low- level data design decisions should be deferred until late in the
design process. The representation of data structure should be known only to those
modules that must make direct use of the data contained within the structure. A library
of useful data structures and the operations that may be applied to them should be
developed. A software design and programming language should support the
specification and realization of abstract data types.

ARCHITECTURAL STYLES AND PATTERNS:

The builder has used an architectural style as a descriptive mechanism to
differentiate the house from other styles (e.g., A-frame, raised ranch, Cape Cod). The
software that is built for computer- based systems also exhibits one of many
architectural styles.

Each style describes a system category that encompasses

A set of components (e.g., a database, computational modules) that perform a
function required by a system;

A set of connectors that enable “communication, coordination and

cooperation” among components

Constraints that define how components can be integrated to form the

system; and Semantic models that enables a designer to understand the overall
properties of a system by analyzing the know properties of its constituent parts.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 117

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

An architectural pattern, like an architectural style, imposes a transformation

the design of architecture. However, a pattern differs from a style in a number of
fundamental ways:

The scope of a pattern is less board, focusing on one aspect of architecture

rather than the architecture its entirety. A pattern imposes a rule on the architecture,
describing how the software will handle some aspect of its functionality at the
infrastructure level. Architectural patterns tend to address specific of behavioral issues
within the context of the architectural.

A Brief Taxonomy of Styles and Patterns 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. A variation on this approach transforms the repository
into a “blackboard” that sends notification to client software when data of interest to
the client changes

Data-centered architectures promote integrability. That is, existing

components can be changed and new client components can be 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

Figure 3.5

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 118

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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 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 of a specified form.

If the data flow degenerates into a single line of transforms, it is termed batch
sequential. This pattern accepts a batch of data and then applies a series of sequential
components (filters) to transform it.

Call and return architectures. This architectural style enables a software

designer (system architect) to achieve a program structure that is relatively easy to
modify and scale. A number of substyles [BAS98] exist within this category:

Figure 3.6

Main program/subprogram architectures. This classic program structure

decomposes function into a control hierarchy where a “main” program invokes a
number of program components, which in turn may invoke still other components.
Figure illustrates an architecture of this type.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 119

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Remote procedure calls 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 is accomplished via message passing.
Layered architectures. The basic structure of a layered architecture is illustrated in
Figure. 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.

Figure 3.7

Architectural Patterns:
An architectural pattern, like an architectural style, imposes a transformation
the design of architecture. However, a pattern differs from a style in a number of
fundamental ways:
 The scope of a pattern is less broad, focusing on one aspect of the architecture
rather than the architecture in its entirety.
 A pattern imposes a rule on the architecture, describing how the software will
handle some aspect of its functionality at the infrastructure level.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 120

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 Architectural patterns tend to address specific behavioral issues within the context
of the architectural.
 The architectural patterns for software define a specific approach for handling
some behavioral characteristics of the system

Concurrency - applications must handle multiple tasks in a manner that simulates

parallelism o operating system process management pattern, task scheduler pattern

Persistence - Data persists if it survives past the execution of the process that created
it. Two patterns are common: a database management system pattern that applies the
storage and retrieval capability of a DBMS to the application architecture an
application level persistence pattern that builds persistence features into the
application architecture
Distribution – the manner in which systems or components within systems
communicate with one another in a distributed environment .A broker acts as a
‘middle-man’ between the client component and a server component.

Organization and Refinement:

The design process often leaves a software engineer 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 the architectural style that has been derived:

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?

Data
How are data communicated between components?
Is the flow of data continuous, or are data objects passed to the system sporadically?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 121

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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?

ARCHITECTURAL DESIGN:
Representing the System in Context:
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 the figure

Super ordinate Systems

Control

Safehome Internet-based
Panel Product system

Homeowner

target
system: surveillance
Security uses function

uses peers

uses

Figure 3.8

Super ordinate systems – those systems that use the target system as part of some
higher level processing scheme.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 122

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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
Actors -those entities that interact with the target system by producing or consuming
information that is necessary for requisite processing

Defining Archetypes:
An archetype is a class or pattern that represents a core abstraction that is
critical to the design of architecture for the target system. In general, a relative small
set of archetypes is required to design even relatively complex systems.
Node: Represent a cohesive collection of input and output elements of the home
security function.
For example a node might be comprised of (1) various sensors, and (2) a variety of
alarm indicators. Detector: An abstraction that encompasses all sensing equipment
that feeds information into the target system
Indicator: An abstraction that represents all mechanisms for indication that an alarm
condition is occurring.
Controller: An abstraction that depicts the mechanism that allows the arming or
disarming of a node. If controllers reside on a network, they have the ability to
communicate with one another.

communicates with

Detector Indicator

Figure 3.9

UML relationships for Safe Home security function archetypes (adapted from [
BOS00] )

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 123

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Designing conventional components

As the architecture is refined into components, the structure of the system
begins to emerge. The architectural designer begins with the classes that were
described as part of the analysis model. These analysis classes represent entities
within the application domain that must be addressed within the software architecture.
Hence, the application domain is one source is the infrastructure domain. The
architecture must accommodate many infrastructure components that enable
application domain. For eg: memory management components, communication
components database components, and task management components are often
integrated into the software architecture. In the safeHome security function example,
we might define the set of top-level components that address the following
functionality

External communication management- coordinates communication of the security

function with external entities

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.

Design classes would be defined for each. It is important to note, however,

that the design details of all attributes and operations would not be specified until
component-level design.

SafeHome
Executive

Funct ion select ion

External
Communication
Management

Securit y Surveillance Home

management

GUI Internet
Interface

Cont rol detector alarm

panel
management proce ssing

processing

Component Structure
Figure 3.10

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 124

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

III Describing Instantiations of the System: An actual instantiation of the

architecture means the architecture is applied to a specific problem with the intent of
demonstrating that the structure and components are appropriate.

Object Constraint Language

Object : An object is an entity that has a state and a defined set of operations that
operate on that state. An object class defination is both a type specification and a
template for creating objects. It includes declaration of all the attributes and
operations that are associated with object of that class.

Object Oriented Design Process

There are five stages of object oriented design process
1. Understand and define the context and the modes of use of the system.
2. Design the system architecture
3. Identify the principle objects in the system.
4. Develop a design models
5. Specify the object interfaces

Systems context and modes of use It specify the context of the system.it also
specify the relationships between the software that is being designed and its external
environment. If the system context is a static model it describe the other system in that
environment. If the system context is a dynamic model then it describe how the system
actually interact with the environment.

System Architecture
Once the interaction between the software system that being designed and the
system environment have been defined. We can use the above information as basis for
designing the System Architecture.

Object Identification
This process is actually concerned with identifying the object classes. We can
identify the object classes by the following:
1) Use a grammatical analysis
2) Use a tangible entities

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 125

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

3) Use a behavioral approach

4) Use a scenario base approach Design model

Design models are the bridge between the requirements and implementation.
There are two type of design models
1) Static model describe the relationship between the objects.
2) Dynamic model describe the interaction between the objects

Object Interface Specification It is concerned with specifying the details of the

interfaces to objects. Design evolution The main advantage OOD approach is to
simplify the problem of making changes to the design. Changing the internal details
of an object is unlikely to effect any other system object.

USER INTERFACE DESIGN

Interface design focuses on three areas of concern:
The design of interfaces between software components, the design of
interfaces between the software and other nonhuman producers and consumers of
information (i.e., other external entities), and the design of the interface between a
human (i.e., the user) and the computer.

What is User Interface Design?

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.

Why is User Interface Design 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 or the functionality it offers. Because it molds a
user’s perception of the software, the interface has to be right.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 126

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

THE GOLDEN RULES

Theo Mandel coins three “golden rules”:
Place the user in control. Reduce the user’s memory load. Make the interface
consistent.
These golden rules actually form the basis for a set of user interface design principles
that guide this important software design activity.

Place the User in Control

Mandel [MAN97] 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
Word processor – spell checking – move to edit and back; enter and exit with little or
no effort Provide for flexible interaction. Several modes of interaction – keyboard,
mouse, digitizer pen or recognition, but not every action is amenable to every
interaction need.
Difficult to draw a circle using keyboard commands.

Allow user interaction to be interruptible and undoable. User stop and do

something and then resume where left off. Be able to undo any action.

Streamline interaction as skill levels advance and allow the interaction to

be customized. Perform same actions repeatedly; have macro mechanism so user can
customize interface.

Hide technical internals from the casual user. Never required to use OS
commands; file management functions or other arcane computing technology.

Design for direct interaction with objects that appear on the screen. User
has feel of control when interact directly with objects; stretch an object.

Reduce the User’s Memory Load:

The more a user has to remember, the more error-prone interaction with the
system will be. Good interface design does not tax the user’s memory System should
remember pertinent details and assist the user with interaction scenario that assists
user recall.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 127

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Mandel defines design principles that enable an interface to reduce the user’s
memory load
Reduce demand on short-term memory. Complex tasks can put a significant burden
on short term memory. System designed to reduce the requirement to remember past
actions and results; visual cues to recognize past actions, rather than recall them.
Establish meaningful defaults. Initial defaults for average user; but specify
individual preferences with a reset option.
Define shortcuts that are intuitive. Use mnemonics like Alt-P.
The visual layout of the interface should be based on a real world metaphor. Bill
payment – check book and check register metaphor to guide a user through the bill
paying process; user has less to memorize

Disclose information in a progressive fashion. Organize hierarchically. High level

of abstraction and then elaborate. Word underlining function – number of functions,
but not all listed. User picks underlining then all options presented

Make the Interface Consistent

Interface present and acquire information in a consistent fashion.All visual
information is organized to a design standard for all screen displays Input mechanisms
are constrained to limited set used consistently throughout the application.
Mechanisms for navigation from task to task are consistently defined and
implemented

Mandel [MAN97] defines a set of design principles that help make the interface
consistent:

Allow the user to put the current task into a meaningful context. Because of many
screens and heavy interaction, it is important to provide indicators – window tiles,
graphical icons, consistent color coding so that the user knows the context of the work
at hand; where came from and alternatives of where to go.

Maintain consistency across a family of applications. For applications or products

implementation should use the same design rules so that consistency is maintained for
all interaction

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 128

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

If past interactive models have created user expectations, do not make changes
unless there is a compelling reason to do so. Unless a compelling reason presents
itself don’t change interactive sequences that have become de facto standards. (alt-S
to scaling)

USER INTERFACE DESIGN

Interface Design Models
Four different models come into play when a user interface is to be designed.
The software engineer creates a design model, a human engineer (or the
software engineer) establishes a user model, the end-user develops a mental image
that is often called the user's model or the system perception, and the implementers of
the system create a implementation model.

The role of interface designer is to reconcile these differences and derive a

consistent representation of the interface.

User Model: The user model establishes the profile of end-users of the system. To
build an effective user interface, "all design should begin with an understanding of the
intended users, including profiles of their age, sex, physical abilities, education,
cultural or ethnic background, motivation, goals and personality" [SHN90]. In
addition, users can be categorized as Novices, Knowledgeable, intermittent users,
Knowledgeable, frequent users.

Design Model: A design model of the entire system incorporates data, architectural,
interface and procedural representations of the software.

Mental Model: The user’s mental model (system perception) is the image of the
system that end- users carry in their heads.

Implementation Model: The implementation model combines the outward

manifestation of the computer- based system (the look and feel of the interface),
coupled with all supporting information (books, manuals, videotapes, help files) that
describe system syntax and semantics.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 129

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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

The User Interface Design Process: (steps in interface design)

The user interface design process encompasses four distinct framework
activities : User, task, and environment analysis and modeling Interface design
Interface construction Interface validation

Figre 3.11

USER INTERFACE DESIGN PROCESS

(1) User Task and Environmental Analysis:
The interface analysis activity 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, the software
engineer attempts to understand the system perception (Section 15.2.1) 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

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 130

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The 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 information gathered as part of the analysis activity is used to create an

analysis model for the interface. Using this model as a basis, the design activity
commences.

(2) Interface Design:

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.

(3) Interface Construction(implementation)

The implementation activity 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.

(4) Interface Validation:

Validation focuses on the ability of the interface to implement every user task
correctly, to accommodate all task variations, and to achieve all general user
requirements; the degree to which the interface is easy to use and easy to learn;

INTERFACE ANALYSIS
A Key tenet of all software engineering process models is this: In the case of
user interface design, understanding the problem means understanding (1) The people
who will interact with the system through the interface; (2) the tasks that tend-users
must perform to do their work, (3) the content that is presented as part of the inter
face, an (4) the environment in which these tasks will be conducted. In the sections
that follow, we examine each of these elements of interface analysis with the intent of
establishing a solid foundation for the design tasks that follow.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 131

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

User analysis
Earlier we noted that each user has a mental image or system perception of the
software that may be different from the mental image developed by other users.

User Interviews. The most direct approach, interviews involve representatives from
the software team who 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
customers an users on 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 definition of market segments

while providing an understanding of how each segment might use the software in
subtly different ways. Support input. Support staff talk with users on a daily basis,
making them the most likely soured of information on what works an 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 (adapted form (HAC98) ) will help the interface
designer better understand the users of a system:
 Are user 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 ecpressed a
desire of 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 the is addressed by the system?
 Do users want to know about the technology that sits behind the interface?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 132

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The answers to these an similar questions will allow the designer to

understand who the end-users are, what is likely to motivate and please them, how
they can be grouped into different user classes or profiled, what their mental models of
the system are, and how the user interface must be characterized to meet their needs.

Task Analysis and Modeling

The goal of talk analysis is to answer the following questions:
 What work will the user perform in specific circumstances?
 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, the software engineer must draw upon analysis
techniques discussed in Chapters 7 and 8, but in this instance, these techniques are
applied to the user interface.

In earlier chapter we noted that the use-case describe the manner in which an
actor (in the context of user interface design, an actor is always a person) interacts
with a system. The use-case provides a basic description of one important work task
for the computer-aided design system. From, it, the software engineer can extract
tasks, objects, and the overall flow of the interaction.

Task elaboration. Task analysis of interface design uses an elaborative approach to

assist in understanding the human activities the user interface must accommodate. To
understand the tasks that must be performed to accomplish the goal of the activity, a
human engineer must understand the tasks that humans 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, the human engineer can study an existing specification for computer-
based solution and derive a set of user tasks that will accommodate the user model,
the design model, and the system perception.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 133

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

For example, assume that a small software company wants to build a computer-aided
design system explicitly for interior designers. By observing an interior designer at
work, the engineer notices that interior design comprises a number of major activities:
further layout (note the use-case discussed earlier), fabric and material selection, wall
and window coverings selection, presentation (to the customer), costing, and
shopping. Each of these major tasks can be elaborated into subtasks.

For example, using information contained in the use- case, furniture layout can be
refined into the following tasks: (1) draw a floor plan based on room dimensions; (2)
place windows and doors at appropriate locations;(3a) use furniture templates to draw
scaled accents on floor plan(4) move furniture outlines;(6) draw dimensions to show
location;(7) draw perspective rendering view for customer. A similar approach could
be used for each of the other major tasks.

Object elaboration. The software engineer extracts 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
the designer with a list of operations.

For example, the furniture template might translate into a class called Furniture with
attributes that might include size, shape, location and others. The interior designer
would select the object from the Furniture class, move it to a position on the floor plan
(another object in this context), draw the furniture outline, and so forth. He tasks
select, move, and draw are operations.

The user interface analysis model would not provide a literal implementation for each
of these operation for each of these operations.

However, as the design is elaborated, the details of each operation are defined.

Workflow analysis. When a number of different users, each playing different roles,
makes uses of a user interface, it is sometimes necessary to go beyond task analysis
and object elaboration and apply workflow analysis. This technique allows a software
engineer to understand how a work process is completed when several people are
involved.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 134

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The flow of events (shown in the figure) enable the interface designer to recognize
three day interface characteristics. Each user implements different tasks via the
interface; therefore, the look and feel of the interface designed for the patient will be
different from the one defined for pharmacists or physicians.

The interface design for pharmacists and physicians must accommodate access to and
display of information form secondary information sources(e.g., access to inventory
of the pharmacist and access to information about alternative medications for the
physician)

Many of the activities noted in the swim lane diagram can be further elaborated using
talk analysis and /or object elaboration(e.g., fills prescription could imply a mail-order
deliver, a visit to a pharmacy, or a visit to a special drug distribution center.

Hierarchical representation. As the interface is analyzed, a process of elaboration

occurs. Once workflow has been established, a task hierarchy can e defined for each
user type. The hierarchy is derived by a stepwise elaboration of each task identified
for the user.

For example, consider the user task requests that a prescription be refilled. The
following task hierarchy is developed: Request that a prescription be refilled is
required.

To complete the request that a prescription be refilled tasks, three subtasks are
defined. One of these subtasks, provide indentifying information, is further elaborated
in three additional sub-subtasks.

Analysis of Display Content

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 the desired output or action. System response time has two important
characteristics: length and variability. If system response is is too long, user frustration
and stress is the inevitable result.
Variability refers to the deviation form average response time, and, in many ways, it is

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 135

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

the most important response time characteristic. Low variability enables the user to
establish an interaction rhythm, even if response time is relatively long. For example,
a 1-second response to a command will often be preferable to a response that varies
from 0.1 to 2.5 seconds. When variability is significant, the user is always off balance,
always wondering whether something “different “has occurred behind the scenes.

Help facilities. Modern software provides on-line 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 day,
or a HELP command.

How will help be represented? Options include a separate window, a reference to a

printed document, 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 in which
all information is accessed through a keyword, a layered hierarchy or information that
provides increasing detail as the user proceeds into the structure, or the user of
hypertext.

In general, every error message or warning produced by an interactive system should

have the following characteristics

The message should describe the problem in language the user can understand. The
message should provide constructive advice for recovering form the error.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 136

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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.

The message should be nonjudgmental. That is, the wording should never place blame
on the user.
But an-effective error message philosophy can do much to improve the quality of an
interactive system and will significantly reduce user frustration when problems do
occur.

A number of design issues arise when typed commands or menu labels are provided
as 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. Accessibility for users and software engineers) who may be
physically challenged is an imperative for moral, 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 vary8ing levels of accessibility.

Others provide specific guidelines or “assistive technology” that addresses the needs
of those with visual, hearing, mobility, speech, and learning impairments.

Internationalization. The challenge should be designed to accommodate a generic

core of functionality that can be delivered to all who use the software. Localization
features enable the interface to be customized for a specific market.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 137

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

A variety of internationalization guidelines are available to software engineers. These

guidelines address broad design issues and discrete implementation issues. The
Unicode standard has been developed to address the daunting challenge of managing
dozens of natural languages with hundred of characters and symbols.

DESIGN EVALUATION
After the design model has been completed, a first-level prototype is created.
The prototype is evaluated by the user, who provides the designer with direct
comments about the efficacy of the interface.

In addition, if formal evaluation techniques are used e.g., questionnaires,

rating sheets), the designer may extract information form these data (e.g., 80percent 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. If
a design model of the interface has been created, a number of evaluation criteria can
be applied during early design reviews:

The length and complexity of the written specification of the system and its
interface provide an indication of the amount of learning required by user of the
system. The number of user tasks specified and the average number of actions per
task provide an indication on interaction time and the overall efficiency of the system.

The number of actions, tasks, and system states indicated by the design model
imply the memory load on users of the system. Interface styles, 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, the designer can collect a variety of
qualitative and quantitative data that will assist in evaluating the interface. To collect
qualitaive 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. Users are observed during interaction, and
data-such as number of tasks correctly completed over a standard time period,

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 138

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

frequency of actions, sequence of actions, time spent “looking” at the display, number
and types of errors, error recovery time, time spent using help, and number of help
references per standard time period-are collected and used as a guide for interface
modification.

Figre 3.12 : Design Evaluation

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 139

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT - IV
TESTING STRATEGIES

Testing is the process of exercising a program with the specific intent of

finding errors prior to delivery to the end user. Testing shows errors, requirements
conformance, performance & indication of quality.

A Strategic Approach To Software Testing.

Test Strategy incorporates test planning, test case design, test execution and
resultant data collection and execution. All provide the software developer with a
template for testing and all have the following generic characteristics:
 Perform Formal Technical reviews(FTR) to uncover errors during software
development
 Begin testing at component level and move outward to integration of entire
component based system.
 Adopt testing techniques relevant to stages of testing
 Testing can be done by software developer and independent testing group
 Testing and debugging are different activities. Debugging follows testing

Verification & Validation

Verification refers to the set of activities that ensure that software correctly
implements a specific function.

Validation refers to a different set of activities that ensure that the software that has
been built is traceable to customer requirements.

Boehm [BOE81] states this way:

Verification: "Are we building the product right?"
Validation: "Are we building the right product?"

The definition of V&V encompasses many of the activities that we have

referred to as software quality assurance (SQA).

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 140

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Verification and validation encompasses a wide array of SQA activities that

include formal technical reviews, quality and configuration audits, performance
monitoring, simulation, feasibility study, documentation review, database review,
algorithm analysis, development testing, qualification testing, and installation testing.
Although testing plays an extremely important role in V&V, many other activities are
also necessary.

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 do? Unfortunately, these same developers have a vested interest in
demonstrating that the program is error free, that it works according to customer
requirements.

From a psychological point of view, software analysis and design (along with
coding) are constructive tasks. From the point of view of the builder, testing can be
considered to be (psychologically) destructive.

The software developer is always responsible for testing the individual units
(components) of the program, ensuring that each performs the function 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 program structure.
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.

However, the software engineer does not turn the program over to ITG and
walk way. 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.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 141

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The ITG is part of the software development project team in the sense that it
becomes involved during the specification activity and stays involved (planning and
specifying test procedures) throughout a large project.

A Software Testing Strategy for Conventional Software Architecture

The software engineering process may be viewed as the spiral illustrated in
Figure18.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.

Figure 4.1 : Testing Strategy

Unit testing begins at the vortex of the spiral and concentrates on each unit (i.e.,
component) 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, we encounter validation testing, where
requirements established as part of software requirements analysis are validated
against the software that has been constructed. Finally, we arrive at system testing,
where the software and other system elements are tested as a whole.

Unit testing makes heavy use of white-box testing techniques. Black-box test case
design techniques are the most prevalent during integration, although a limited
amount of white-box testing may be used to ensure coverage of major control paths.
Black-box testing techniques are used exclusively during validation. Software, once

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 142

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

validated, must be combined with other system elements (e.g., hardware, people, and
databases). System testing verifies that all elements mesh properly and that overall
system function/performance is achieved.

Figure 4.2

Test Strategies For Conventional Software

Unit Testing

Figure 4.3

This is a fig just to understand 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 unit test is white-box oriented.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 143

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Unit Test Considerations

The tests that occur as part of unit tests are illustrated schematically in Figure
18.4. The module interface is tested to ensure that information properly flows into and
out of the program unit under test. The local data structure is examined to ensure that
data stored temporarily maintains its integrity during all steps in an algorithm's
execution. Boundary conditions are tested to ensure that the module operates properly
at boundaries established to limit or restrict processing. All independent paths (basis
paths) through the control structure are exercised to ensure that all statements in a
module have been executed at least once. And finally, all error handling paths are
tested.

Figure 4.4

What errors are commonly found during Unit Testing?

(1) Misunderstood or incorrect arithmetic precedence, (2) mixed mode operations, (3)
incorrect initialization, (4) precision inaccuracy, (5) incorrect symbolic representation
of an expression. Comparison and control flow are closely coupled to one another
(i.e., change of flow frequently occurs after a comparison).

Test cases should uncover errors such as

(1) comparison of different data types, (2) incorrect logical operators or
precedence,(3) expectation of equality when precision error makes equality unlikely,
(4) incorrect comparison of variables, (5) improper or nonexistent loop termination,

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 144

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

(6) failure to exit when divergent iteration is encountered, and (7) improperly
modified loop variables.

Unit Test Procedures

After source level code has been developed, reviewed, and verified for
correspondence to component- level design, unit test case design begins

Figure 4.5

Because a component is not a stand-alone program, driver and/or stub software

must be developed for each unit test. The unit test environment is illustrated in Figure
18.5. 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 (called 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. Unit testing is simplified when a component with high
cohesion is designed

Integration Testing
The objective is to take unit tested components and build a program structure
that has been dictated by design.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 145

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Options: "big bang" approach All components are combined in advance. The entire
program is tested as a whole. Incremental integration The program is constructed
and tested in small increments, where errors are easier to isolate and corrected.

Numbers of different incremental integration strategies are discussed Top-Down

Integration Modules are integrated by moving downward through the control
hierarchy, beginning with the main control module (main program). Modules
subordinate to the main control module are incorporated into the structure in either a
depth-first or a breadth-first manner.

Referring to fig 18.6 depth-first integration would integrate all components on a major
control path of the structure. Selection of a major path 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.

Figure 4.6 : Top-down Integration

Breadth-first integration incorporates all components directly subordinate at each

level, moving across the structure horizontally. From the figure, components M2, M3,
and M4 (a replacement for stub S4) would be integrated first. The next control level,
M5, M6, and so on, follows.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 146

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Steps for Top-Down Integration:

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

What problems are encountered when top-down integration strategy is chosen?

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

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

Steps for Bottom-Up Integration

1. Low-level components are combined into clusters (sometimes-called builds) that
perform a specific software sub function.
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.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 147

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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.

Figure 4.7: Bottom-up Integration

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. Regression testing is the re- execution of some subset of tests that
have already been conducted to ensure that changes have not propagated unintended
side effects.

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.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 148

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Smoke Testing
Smoke testing is an integration testing approach that is commonly used when
“shrink-wrapped” software products are being developed. It is designed as a pacing
mechanism for time-critical projects

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 “show stopper” 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, time-

critical software engineering projects:
 Integration risk is minimized..
 The quality of the end-product is improved.
 Progress is easier to assess.

Comments on Integration Testing

The major disadvantage of the top-down approach is the need for stubs and the
attendant testing difficulties that can be associated with them.

The major disadvantage of bottom-up integration is that "the program as an

entity does not exist until the last module is added"

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.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 149

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 4.8 : Sandwich Testing

What is a critical module and why should we identify it?

• Address several software requirements
• Has a high level of control (high in the program structure) structure)
• Is complex or error prone
• Has definite performance requirements
Validation Testing
Validation succeeds when software functions in a manner that can be
reasonably expected by the customer

Validation Test Criteria

Software validation is achieved through a series of black-box tests that
demonstrate conformity with requirements. Both the plan and procedure are designed
to ensure that all functional requirements are satisfied, all behavioral characteristics
are achieved, all performance requirements are attained, documentation is correct and
human-engineered and other requirements are met.

After each validation test case has been conducted, one of two possible conditions
exist:
1. The function or performance characteristics conform to specification and are
accepted
2. a deviation from specification is uncovered and a deficiency list is created.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 150

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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 phase of the software life cycle. The configuration review, sometimes called
an audit.

Alpha and Beta Testing

A customer conducts the alpha test at the developer’s site. The beta test is
conducted at one or more customer sites by the end-user of the software. Unlike alpha
testing, the developer is generally not present

System Testing
Software is incorporated with other system elements (e.g., hardware, people,
information), and a series of system integration and validation tests are conducted.
These tests fall outside the scope of the software process and are not conducted solely
by software engineers. A classic system-testing problem is "finger- pointing." This
occurs when an error is uncovered, and each system element developer blames the
other for the problem.

Recovery Testing
Recovery testing is a system test that forces the software to fail in a variety of
ways and verifies that recovery is properly performed.

Security Testing
Security testing attempts to verify that protection mechanisms built into a
system. During security testing, the tester plays the role(s) of the individual who
desires to penetrate the system.

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,

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 151

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

3. Test cases that require maximum memory or other resources are executed,
Essentially, the tester attempts to break the program.
A variation of stress testing is a technique called sensitivity testing. Sensitivity
testing attempts to uncover data combinations within valid input classes that may
cause instability or improper processing

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.
Performance tests are often coupled with stress testing and usually require
both hardware and software instrumentation.

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.

The Debugging Process

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.

Figure 4.9 : The Debugging Process

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 152

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The debugging process will always have one of two outcomes:

(1) The cause will be found and corrected, or
(2) The cause will not be found.

Debugging Approaches
In general, three categories for debugging approaches may be proposed
1)brute force, (2) backtracking, and (3) cause elimination.

The brute force category of debugging is probably the most common and least
efficient method for isolating the cause of a software error. We apply brute force
debugging methods when all else fails

Backtracking is a 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 site of the cause is found.

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.

Once a bug has been found, it must be corrected. However, as we have already
noted, the correction of a bug can introduce other errors and therefore do more harm
than good.

Van Vleck [VAN89] suggests three simple questions that every software
engineer 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?
2. What "next bug" might be introduced by the fix I am about to make?
3. What could we have done to prevent this bug in the first place?

White-Box Testing
White-box testing, sometimes called glass-box testing. Our goal is to ensure that all
statements and conditions have been executed atleast once. Using white-box testing
methods, the software engineer can derive test cases that

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 153

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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
4. Exercise internal data structures to ensure their validity.

Basis Path Testing

Basis path testing is a white-box testing technique first proposed by Tom
McCabe. Test cases derived to exercise the basis set are guaranteed to execute every
statement in the program at least one time during testing.

Flow Graph Notation

Figure 4.10: Flow graph notation

Before the basis path method can be introduced, a simple notation for the
representation of control flow, called a flow graph (or program graph) must be
introduced.

Each circle, called a flow graph node, represents one or more procedural
statements. The arrows on the flow graph, called edges or links, represent flow of
control. Each node that contains a condition is called a predicate node and is
characterized by two or more edges emanating from it.

Cyclomatic Complexity
Cyclomatic complexity is software metric that provides a quantitative measure
of the logical complexity of a program. 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 us with an upper bound
for the number of tests that must be conducted to ensure that all statements have been
executed at least once.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 154

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 4.11

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 before the path is defined.

In the above fig the set of independent paths are as follows:

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 an independent path because it is simply a combination of already
specified paths and does not traverse any new edges.
Paths 1, 2, 3, and 4 constitute a basis set for the above flow graph

How is Cyclomatic complexity computed?

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

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 155

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Referring once more to the above flow graph 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.cyclomatic complexity for above flow graph

Deriving Test Cases

Figure 4.12 : PDL for test base design with nodes identified

Using the above PDL let us describe how derive the test cases The following
steps are used to derive the set of test cases

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 156

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

1. Using the design or code as a foundation, draw a corresponding flow graph

Figure 4.13

2. Determine the cyclomatic complexity of the resultant flowgraph. 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 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

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 157

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

4. Prepare test cases that will force execution of each path in the basis set.
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 least once.

Graph Matrices
To develop a software tool that assists in basis path testing, a data structure,
called a graph matrix, can be quite useful.
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 below figure.

Figure 4.14

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 158

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

What is a graph matrix and how do we extend it use for testing? The graph
matrix is nothing more than a tabular representation of a flow graph. by adding a link
weight to each matrix entry, the graph matrix can become a powerful tool for
evaluating program control structure during testing

In its simplest form, the link weight is 1 (a connection exists) or 0 (a

connection does not exist). Represented in this form, the graph matrix is called a
connection matrix.

Referring to above figure each row with two or more entries represents a
predicate node. Performing the arithmetic shown to the right of the connection matrix
provides us with still another method for determining Cyclomatic complexity

Control Structure Testing

These broaden testing coverage and improve quality of white-box testing

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), >, or ≥.

A compound condition is composed of two or more simple conditions,

Boolean operators, and parentheses. A condition without relational expressions is
referred to as a Boolean expression.

Types of errors in a condition include the following:

Boolean operator error (incorrect/missing/extra Boolean operators), Boolean
variable error, Boolean parenthesis error, Relational operator error and Arithmetic
expression error.

The purpose of condition testing is to detect not only errors in the conditions
of a program but also other errors in the program

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 159

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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 at statement 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 the 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.

Loop Testing
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 17.8)

Figure 4.15 : Causes of Loops

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 160

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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
their minimum iteration parameter (e.g., loop counter) 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

BLACK-BOX TESTING
Black-box testing, also called behavioral testing, focuses on the functional
requirements of the software.

Black -box testing enables the software engineer to derive sets of input conditions that
will fullyexercise all functional requirements for a program.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 161

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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 data base access,
(4) Behavior or performance errors, and
(5) Initialization and termination errors.

White-box testing, which is performed early in the testing process, blackbox testing
tends to be applied during later stages of testing.

Graph-Based Testing Methods

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.

Figure 4.16 : (A) Graph Notation (B)Simple Example

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 162

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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.

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.

Referring to the figure, a menu select on new file generates a document

window. The node weight of document window 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 new file menu select and document
text, and parallel links indicate relationships between document window and
document text.

The software engineer then derives test cases by traversing the graph and
covering each of the relationships shown. These test cases are designed in an attempt
to find errors in any of the relationships.

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

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 163

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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.

Test cases are selected so that the largest number of attributes of an

equivalence class are exercised at once.

Boundary Value Analysis

Number of errors tends to occur at the boundaries of the input domain rather
than in the "center”. Boundary value analysis leads to a selection of test cases that
exercise bounding values. 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

How do I create BVA test cases?

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 vs. 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., an array has a
defined limit of 100 entries), be certain to design a test case to exercise the data
structure at its boundary.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 164

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Orthogonal Array Testing

The orthogonal array testing method is particularly useful in finding errors
associated with 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.
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).

Figure 4.17 : A geometric view of test access (PHA 97)

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 black dots in the figure) are “dispersed uniformly throughout the test
domain,”
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

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 165

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

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 in the following manner:
An L9 Orthogonal Array
Test Parameters
Test Code
P1 P2 P3 P4
1 1 1 1 1
2 1 2 2 2
3 1 3 3 3
4 2 1 2 3
5 2 2 3 1
6 2 3 1 2
7 3 1 3 2
8 3 2 1 3
9 3 2 1 3

Product Metrics SOFTWARE QUALITY

Software quality is defined as the conformance to explicitly stated functional
and performance requirements, explicitly documented development standards, and
implicit characteristics that are expected of all professionally developed software

McCall’s Quality Factors

Factors that affect software quality can be categorized in two broad groups:
1. Factors that can be directly measured (e.g. defects uncovered during testing)
2. Factors that can be measured only indirectly (e.g. usability or maintainability)

Figure 4.18 : McCalls Software Quality Factors

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 166

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure focus on three important aspects of a software product: its operational

characteristics, its ability to undergo change, and its adaptability to new environments.

McCall and his colleagues provide the following descriptions:

Correctness. The extent to which a program satisfies its specification and fulfills the
customer's mission objectives.

Reliability. The extent to which a program can be expected to perform its intended
function with required precision. [It should be noted that other, more complete
definitions of reliability have been proposed.

Efficiency. The amount of computing resources and code required by a program to

perform its function.

Integrity. Extent to which access to software or data by unauthorized persons can be

controlled.

Usability. Effort required to learn, operate, prepare input, and interpret output of a
program. Maintainability. Effort required to locate and fix an error in a program.
[This is a very limited definition.] Flexibility. Effort required to modify an
operational program. Testability. Effort required to test a program to ensure that it
performs its intended function.

Portability. Effort required to transfer the program from one hardware and/or
software system environment to another.

Reusability. Extent to which a program [or parts of a program] can be reused in other
applications— related to the packaging and scope of the functions that the program
performs.

Interoperability. Effort required to couple one system to another

ISO 9126 Quality Factors

The ISO 9126 standard was developed in an attempt to identify the key quality
attributes for computer software. The standard identifies six key quality attributes:

Functionality. The degree to which the software satisfies stated needs as indicated by
the following sub attributes: suitability, accuracy, interoperability, compliance, and
security.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 167

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Reliability. The amount of time that the software is available for use as indicated by
the following sub attributes: maturity, fault tolerance, recoverability.

Usability. The degree to which the software is easy to use as indicated by the
following sub attributes: understandability, learnability, operability.

Efficiency. The degree to which the software makes optimal use of system resources
as indicated by the following sub attributes: time behavior, resource behavior.

Maintainability. The ease with which repair may be made to the software as
indicated by the following sub attributes: analyzability, changeability, stability,
testability.

Portability. The ease with which the software can be transposed from one
environment to another as indicated by the following sub attributes: adaptability,
installability, conformance, replaceability.

Measures, Metrics and Indicators

 A measure provides a quantitative indication of the extent, amount, dimension,
capacity, or size of some attribute of a product or process
 The IEEE glossary defines a metric as “a quantitative measure of the degree to
which a system, component, or process possesses a given attribute.”
 An indicator is a metric or combination of metrics that provide insight into the
software process, a software project, or the product itself

Metrics for Analysis model

These metrics examine the analysis model with the intent of predicting the “size” of
the resultant system. Size is an indicator of design complexity and is almost always an
indicator of increased coding, integration and testing effort

Function-Based Metrics
The function-point metric can be used effectively as a means for measuring the
functionality delivered by the system.
Using historical data FP metric can be used to
1. Estimate cost or effort required to design code and test the software.
2. Predict no.of errors that will be encountered during testing
3. Forecast no.of components and no.of projected source lines in the implemented
system.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 168

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Function points are derived using an empirical relationship based on countable

measures of software information domain.

Number of External inputs (EI): Each external input originates from a user
or is transmitted from another application. Inputs are often used to update Internal
Logic Files.

Number of External Outputs: Each external output is derived data within the
application that provides information to the user. External outputs refer to reports,
screens, error messages

Number of external inquiries: An external inquiry is defined as an online input that

results in generation of some intermediate software response in form of an online
output

Number of internal logical files: Each internal logical file is a logical grouping of
data that resides within the applications boundary and is maintained via external
inputs.

Number of external interface files: Each external interface file is a logical grouping
of data that resides external to application but provides information that may be of use
to application

Three user inputs—password, panic button, and activate/deactivate—are shown in the

figure along with two inquires—zone inquiry and sensor inquiry. One file (system
configuration file) is shown. Two user outputs (messages and sensor status) and four
external interfaces (test sensor, zone setting, activate/deactivate, and alarm alert) are
also present. These data, along with the appropriate complexity, are shown in Figure
4.19.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 169

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 4.19: Part of the analysis model for safehome software

The count total shown in Figure 19.4 must be adjusted using Equation
FP = count total * [0.65 + 0.01* ∑(Fi)]
where count total is the sum of all FP entries obtained from Figure 19.3 and Fi (i = 1to
14) are "complexit y adjustment values." For the purposes of this example, we assume
that (∑Fi) is 46 (a moderately complex product). Therefore,
FP = 50 * [0.65 + 0.01 *46] = 56

Metrics for specification of quality

List of characteristics that can be used to assess the quality of the analysis
model and the corresponding Metrics for specification of quality requirements
specification: specificity (lack of ambiguity), completeness, correctness,
understandability, verifiability, internal and external consistency, achievability,
concision, traceability, modifiability, precision, and reusability. We assume that there
are Nr requirements in a specification, such that

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 170

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Where nf is the number of functional requirements and Nnf is the number of non-
functional (e.g., performance) requirements.
To determine the specificity (lack of ambiguity) of requirements

is the number of requirements for which all reviewers had identical

interpretations. The closer the value of Q to 1, the lower is the ambiguity of the
specification.

The completeness of functional requirements can be determined by computing the

ratio

is the number of unique function requirements, , is the number of inputs (stimuli)

defined or implied by the specification, and ns is the number of states specified. The
Q2 ratio measures the percentage of necessary functions that have been specified for a
system

Metrics for design model

Architectural Design Metrics
Architectural design metrics focus on characteristics of the program architecture.
These metrics are black box in the sense that they do not require any knowledge of the
inner workings of a particular software component.

Card and Glass define three software design complexity measures: structural
complexity, data complexity, and system complexity.

Structural complexity of a module i is defined in the following manner:

S(i) = f 2out(i)
where fout(i) is the fan-out of module i.(Fan-out means number of modules directly
sub-ordinate to module i)
Data complexity provides an indication of the complexity in the internal interface for
a module i and is defined as
D(i) = v(i)/[ fout(i) +1]
where v(i) is the number of input and output variables that are passed to and from
module i.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 171

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

System complexity is defined as the sum of structural and data complexity, specified
as C(i) = S(i) + D(i)

As each of these complexity values increases, the overall architectural complexity of

the system also increases. This leads to a greater likelihood that integration and testing
effort will also increase.

Morphology (shape) metrics: a function of the number of modules and the number
of interfaces between modules
size = n + a

Figure 4.20
where n is the number of nodes and a is the number of arcs. For the architecture
shown in Figure 19.5,
size = 17 + 18 = 35
depth = the longest path from the root (top) node to a leaf node. For the architecture
shown in Figure 19.5, depth = 4.
width = maximum number of nodes at any one level of the architecture. For the
architecture shown in Figure 19.5, width = 6.arc-to-node ratio, r = a/n, r = 18/17 =
1.06.
DSQI(Design Structure Quality Index)
 US air force has designed the DSQI
 Compute s1 to s7 from data and architectural design
 S1:Total number of modules
 S2:Number of modules whose correct function depends on the data input

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 172

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 S3:Number of modules whose function depends on prior processing

 S4:Number of data base items
 S5:Number of unique database items
 S6: Number of database segments
 S7:Number of modules with single entry and exit
 Calculate D1 to D6 from s1 to s7 as follows:
 D1=1 if standard design is followed otherwise D1=0
 D2(module independence)=(1-(s2/s1))
 D3(module not depending on prior processing)=(1-(s3/s1))
 D4(Data base size)=(1-(s5/s4))
 D5(Database compartmentalization)=(1-(s6/s4)
 D6(Module entry/exit characteristics)=(1-(s7/s1))

DSQI=∑ WiDi
where i = 1 to 6, wi
is the relative weighting of the importance of each of the intermediate values, and
∑wi= 1 (if all Di are weighted equally, then wi= 0.167).
DSQI of present design be compared with past DSQI. If DSQI is significantly lower
than the average, further design work and review are indicated
Metrics for Object-oriented design
Whitmire [WHI97] describes nine distinct and measurable characteristics of an OO
design: Size : Size is defined in terms of four views: population, volume, length, and
functionality Complexity
How classes of an OO design are interrelated to one another
Coupling The physical connections between elements of the OO design
Sufficiency “the degree to which an abstraction possesses the features required of it,
or the degree to which a design component possesses features in its abstraction, from
the point of view of the current application.”
Completeness An indirect implication about the degree to which the abstraction or
design component can be reused
Cohesion The degree to which all operations working together to achieve a single,
well-defined purpose
Primitiveness Applied to both operations and classes, the degree to which an
operation is atomic

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 173

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Similarity The degree to which two or more classes are similar in terms of their
structure, function, behavior, or purpose
Volatility Measures the likelihood that a change will occur
Class-Oriented Metrics-The CK Metrics suite
Proposed by Chidamber and Kemerer
weighted methods per class : Assume that n methods of complexity c1,c2,-cn are
defines for a class C
WMC=∑ci for i=1 ton
The number of methods and their complexity are reasonable indicators of amount or
effort required to implement and test a class

Figure 4.21

Depth of the inheritance tree : Max length form node to root of tree referring to fig
DIT=4 As DIT grows low-level classes will inherit many methods this leads to many
difficulties & greater design complexity

Number of children: The subclasses that are immediately subordinate to a class in

class hierarchy are termed its children. As NOC grows reuse increases but abstraction
represented by parent class is diluted if some children are not appropriate members of
parent class.

Coupling between object classes: As CBO increases reusability decreases

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 174

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Response for a class :A set of methods that can potentially be executed in response to
a message.RFC is no. of methods in response set. As RFC increases complexity
increases. Lack of cohesion in methods: LCOM is no. of methods that access one or
more of same attributes. If no methods access same attribute LCOM=0

Class-Oriented Metrics: The MOOD Metrics Suite Method inheritance factor

Where the summation occurs over i = 1 to Tc. Tc is defined as the total number of
classes in the architecture; Ci is a class within the architecture; and

Where = the number of methods that can be involved in association with Ci.

= the number of methods declared in the class Ci.

= the number of methods inherited (and not overridden) in Ci.

where the summations occur over i = 1 to TC and j = 1 to TC. The function

is_client = 1, if and only if a relationship exists between the client class, CC, and the
server class CS, and CC  CS = 0, otherwise
If CF increases the complexity of OO software also increases.

Class-Oriented Metrics Proposed by Lorenz and Kidd

Lorenz and Kidd divide class-based metrics into four broad categories

Size-oreinted metrics: focus on count of attributes and operations for an individual

class Inheritance- based metrics: focus on manner in which operations are reused
through class hierarchy Merics for class internal : focus on cohesion
Metrics for external : focus on coupling
Component-Level design metrics
Cohesion metrics: a function of data objects and the focus of their definition
d0 = number of output data parameters
c0 = number of output control parameters
For Global coupling
gd = number of global variables used as data

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 175

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

gc = number of global variables used as control

For environmental coupling
w = number of modules called (fan-out)
r = number of modules calling the module under consideration (fan-in)
Using these measures, a module coupling indicator, mc is defined in the following
way:
mc = k/M
where k is a proportionality constant and

Values for k, a, b and c must be delivered empirically

As the value of mc increases, the overall module coupling decreases. In order to have
the coupling metric move upward as the degree of coupling increases, a revised
coupling metric may be defined as
C = 1 – mc

Coupling metrics: a function of input and output parameters, global variables, and
modules called

Complexity metrics: hundreds have been proposed (e.g., Cyclomatic complexity)

Operation-Oriented Metrics
 average operation size
 operation complexity
 average number of parameters per operation

Interface Design Metrics

Layout appropriateness: a function of layout entities, the geographic position and the
“cost” of making transitions among entities. This is a worthwhile design metric for
interface design.

Metrics for source code

 HSS(Halstead Software science)
 Primitive measure that may be derived after the code is generated or estimated
once design is complete

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 176

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

 n1 = the number of distinct operators that appear in a program

 n2 = the number of distinct operands that appear in a program
 N1 = the total number of operator occurrences.
 N2 = the total number of operand occurrence.

Length N = n1 log2 n1 + n2 log2 n2 Program volume V = N log2 (n1 + n2)

Volume ratio L=2/n1 * n2/N2
Metrics for Testing
 Program Level and Effort
 PL = 1/[(n1 / 2) x (N2 / n2 l)]
 e = V/PL

Metrics for maintenance

IEEE standard suggests a software maturity index that provides indication of stability
of software product.
 Mt = the number of modules in the current release
 Fc = the number of modules in the current release that have been changed
 Fa = the number of modules in the current release that have been added.
 Fd = the number of modules from the preceding release that were deleted in the
current release
 The Software Maturity Index, SMI, is defined as:
 SMI = [Mt – (Fc + Fa + Fd)/ Mt ]

Metrics for Process and Projects

Process metrics are collected across all projects and over long periods of time. Their
aim is to provide set of process indicators that lead to long term software process
improvement

Project Metrics enable a software project manager to

1) Assess status of an ongoing project
2) Track potential risks
3) Uncover problem areas before they go critical
4) Adjust workflow
5) Evaluate project teams ability to control quality

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 177

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Figure 4.22
Software Measurement
Software measurement can be categorized as

Direct Measurement
 Direct measure of software process include cost and effort
 Direct measure of product includes lines of code, Execution speed, memory size,
defects per reporting time.

Indirect Measurement
 Indirect measure examines the quality of software product itself(e.g. :-
functionality, complexity, efficiency, reliability and maintainability)

Reasons for measurement

1) To gain baseline for comparison with future assessment
2) To determine status with respect to plan
3) To predict the size, cost and duration estimate
4) To improve the product quality and process improvement

The metrics in software Measurement are

 Size oriented metrics
 Function oriented metrics
 Object oriented metrics
 Web based application metric

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 178

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Size oriented metrics

 It totally concerned with the measurement of software.
 A software company maintains a simple record for calculating the size of the
software. It includes
 errors per KLOC (thousand lines of code)
 defects per KLOC
 $ per LOC
 pages of documentation per KLOC
 errors per person-month
 Errors per review hour
 LOC per person-month
 $ per page of documentation

Function Oriented Metrics

 Measures the functionality derived by the application
 The most widely used function oriented metric is Function point
 Function point is independent of programming language

Typical Function-oriented metrics

errors per FP (thousand lines of code),defects per FP,$ per FP,pages of documentation
per FP,FP per person-month

Object-Oriented Metrics
Relevant for object oriented programming Based on the following

Number of scenario scripts (use-cases)

Number of key classes Key classes are highly independent components that are
defined early in object- oriented analysis
Number of support classes required to implement the system but are not
immediately related to the problem domain
Average number of support classes per key class (analysis class)
Number of subsystems an aggregation of classes that support a function that is
visible to the end-user of a system

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 179

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Use-Case Oriented Metrics

Web Engineering Project Metrics Measures that can be collected are
 Number of static Web pages the end-user has no control over the content
displayed on the page
 Number of dynamic Web pages end-user actions result in customized content
displayed on the page
 Number of internal page links (internal page links are pointers that provide a
hyperlink to some other Web page within the WebApp
 Number of persistent data objects As the number of persistent data objects
grows the complexity of webapps also grows
 Number of external systems interfaced As the requirement for interfacing
grows, system complexity and development effort also increases
 Number of static content objects They encompass graphical, audio, video
information incorporated into the webapp
 Number of dynamic content objects Generated based on end-user actions
We can define a metric that reflects degree of end-user customization for webapp to
effort expended on web-project
Nsp=number of static pages Ndp=number of dynamic pages Customization index
C=Ndp/(Ndp+Nsp)

Metrics for Software Quality

The overriding goal of software engineering is to produce a high-quality system,
application, or product. To achieve this goal, software engineers must apply effective
methods coupled with modern tools within the context of a mature software process.

Measuring Quality
Correctness the degree to which a program operates according to specification
Correctness=defects/KLOC
Maintainability the degree to which a program is amenable to change
Integrity the degree to which a program is impervious to outside attack
Integrity=Sigma[1-(threat(1-security))]
1. Threat : Probability that an attack of specific type will occur within a given time
2. Security : Probability that an attack of a specific type will be repelled
Usability the degree to which a program is easy to use

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 180

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Defect Removal Efficiency

A quality metric that provides benefit at both the project and process level is defect
removal efficiency (DRE) DRE is defined in the following manner:
DRE = E/(E + D)
E is the number of errors found before delivery of the software to the end-user D is
the number of defects found after delivery
Ideal value of DRE is 1, That is no defects found in software.

As E increases (for a given value of D), the overall value of DRE begins to approach
1. In fact, as E increases, it is likely that the final value of D will decrease (errors are
filtered out before they become defects).

DRE can also be used within the project to assess a team’s ability to find errors before
they are passed to the next framework activity or software engineering task.
When used in this context, we redefine DRE as DREi= Ei/(Ei+ Ei+1)
where Ei is the number of errors found during software engineering activity i
Ei+1 is the number of errors found during software engineering activity i+1 that are
traceable to errors that were not discovered in software engineering activity i.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 181

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT - V
RISK MANAGEMENT

Risk is an undesired event or circumstance that occur while a project is underway. It

is necessary for the project manager to anticipate and identify different risks that a
project may be susceptible to.

Risk Management aims at reducing the impact of all kinds of risk that may affect a
project by identifying, analyzing and managing them

Reactive vs Proactive Risk Strategies

Reactive Risks: project team reacts to risks when they occur. The team flies into
action in an attempt to correct the problem rapidly. This is often called a fire fighting
mode. When this fails, “crisis management” takes over and the project is in real
jeopardy.
Proactive Risks: Potential risks are identified, their probability and impact are
assessed, and they are ranked by importance.
The software team establishes a plan for managing risk. The primary objective is to
avoid risk, but because not all risks can be avoided, the team works to develop a
contingency plan that will enable it to respond in a controlled and effective manner.

Software Risks
Risk always involves two characteristics
Uncertainty the risk may or may not happen
Loss if the risk becomes a reality, unwanted consequences or losses will occur.
When risks are analyzed, it is important to quantify the level of uncertainty and the
degree of loss associated with each risk

The type of risks that we likely encounter as software is built?

Project risk: Threaten the project plan and affect schedule and resultant cost
Technical risk: Threaten the quality and timeliness of software to be produced
Business risk: Threaten the viability of software to be built
Known risk: These risks can be recovered from careful evaluation

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 182

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Predictable risk: Risks are identified by past project experience

Unpredictable risk: Risks that occur and may be difficult to identify

Risk Identification
Risk identification is a systematic attempt to specify threats to the project plan
(estimates, schedule, resource loading, etc.). By identifying known and predictable
risks, the project manager takes a first step toward avoiding them when possible and
controlling them when necessary.
Two distinct types of risks for each category of risks specified above
Generic risks are a potential threat to every software project.
Product-specific risks can be identified only by those with a clear understanding of
the technology, the people, and the environment that is specific to the project at hand.
One method for identifying risks is to create a risk item checklist. The checklist can
be used for risk identification
Product size risks associated with the overall size of the software to be built or
modified.
Business impact risks associated with constraints imposed by management or the
marketplace.
Customer characteristics risks associated with the sophistication of the customer
and the developer's ability to communicate with the customer in a timely manner.
Process definition risks associated with the degree to which the software process has
been defined
Development environment risks associated with the availability and quality of the
tools to be used to build the product.
Technology to be built risks associated with the complexity of the system to be built
and the "newness" of the technology that is packaged by the system.
Staff size and experience risks associated with the overall technical and project
experience of the software engineers who will do the work.
Assessing Project Risk
Have top software and customer managers formally committed to support the project?
Are end-users enthusiastically committed to the project and the system/product to be
built? Are requirements fully understood by the software engineering team and their
customers?
Have customers been involved fully in the definition of requirements? Do end-users

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 183

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

have realistic expectations? Is project scope stable?

Does the software engineering team have the right mix of skills? Are project
requirements stable?
Does the project team have experience with the technology to be implemented? Is the
number of people on the project team adequate to do the job?
Do all customer/user constituencies agree on the importance of the project and on the
requirements for the system/product to be built?

Risk Components and Drivers

The risk components are defined in the following manner.
 Performance risk—the degree of uncertainty that the product will meet its
requirements and be fit for its intended use.
 Cost risk—the degree of uncertainty that the project budget will be maintained.
 Support risk—the degree of uncertainty that the resultant software will be easy to
correct, adapt, and enhance.
 Schedule risk—the degree of uncertainty that the project schedule will be
maintained and that the product will be delivered on time.
The impact of each risk driver on the risk component is divided into one of four
impact categories— negligible, marginal, critical, or catastrophic.

Risk Projection
It estimates the impact of risk on the project and the product
Risk projection, also called risk estimation, attempts to rate each risk in two ways
 The likelihood or probability that the risk is real
 The consequences of the problems associated with the risk, should it occur.

The project planner, along with other managers and technical staff, performs four risk
projection activities
 Establish a scale that reflects the perceived likelihood of a risk
 Delineate the consequences of the risk
 Estimate the impact of the risk on the project and the product, note the overall
accuracy of the risk projection so that there will be no misunderstandings

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 184

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Developing a Risk Table

A risk table provides a project manager with a simple technique for risk projection
Impact values
Catastrophic-1 Critical-2 Marginal-3 Negligible-4

Figure 5.1

A project team begins by listing all risks This can be accomplished with the
help of the risk item checklists Each risk is categorized in the second column (e.g.,PS
implies a project size risk, BU implies a business risk).

The probability of occurrence of each risk is entered in the next column of the
table. The probability value for each risk can be estimated by team members
individually. Next, the impact of each risk is assessed

Once the first four columns of the risk table have been completed, the table is
sorted by probability and by impact. High-probability, high-impact risks percolate to
the top of the table, and low-probability risks drop to the bottom. This accomplishes
first-order risk prioritization.

The project manager studies the resultant sorted table and defines a cutoff line.
The cutoff line (drawn horizontally at some point in the table) implies that only risks
that lie above the line will be given further attention. Risks that fall below the line are
re-evaluated to accomplish second-order prioritization.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 185

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Referring to Figure 6.3, risk impact and probability have a distinct influence
on management concern. A risk factor that has a high impact but a very low
probability of occurrence should not absorb a significant amount of management time.

However, high-impact risks with moderate to high probability and low-impact

risks with high probability should be carried forward into the risk analysis steps that
follow.

Figure 5.2 : Risk and Management Concern

The column labeled RMMM contains a pointer into a Risk Mitigation,

Monitoring and Management Plan or alternatively, a collection of risk information
sheets developed for all risks that lie above the cutoff.

Assessing Risk Impact

The overall risk exposure, RE, is determined using the following relationship
RE = P x C
Where
P is the probability of occurrence for a risk, and C is the cost to the project should the
risk occur
For example, assume that the software team defines a project risk in the following
manner:

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 186

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Risk identification. Only 70 percent of the software components scheduled for reuse
will, in fact, be integrated into the application. The remaining functionality will have
to be custom developed.
Risk probability. 80% (likely).
Risk impact. 60 reusable software components were planned. If only 70 percent can
be used, 18 components would have to be developed from scratch (in addition to other
custom software that has been scheduled for development). Since the average
component is 100 LOC and local data indicate that the software engineering cost for
each LOC is $14.00,
The overall cost (impact) to develop the components would be 18 x 100 x 14 =
$25,200. Risk exposure. RE = 0.80 x 25,200 ~=$20,200.

Risk Refinement
One way to do this is to represent the risk in condition-transition-consequence (CTC).

Using the CTC format for the reuse risk we can write:
Given that all reusable software components must conform to specific design
standards and that some do not conform, then there is concern that (possibly) only 70
percent of the planned reusable modules may actually be integrated into the as-built
system, resulting in the need to custom engineer the remaining 30 percent of
components.
This general condition can be refined in the following manner:
Subcondition 1. Certain reusable components were developed by a third party with no
knowledge of internal design standards.

Subcondition 2. The design standard for component interfaces has not been solidified
and may not conform to certain existing reusable components.

Subcondition 3. Certain reusable components have been implemented in a language

that is not supported on the target environment.

Risk Mitigation Monitoring and Management

Its goal is to assist project team in developing a strategy for dealing with risk
If a software team adopts a proactive approach to risk, avoidance is always the best

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 187

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

strategy. This is achieved by developing a plan for risk mitigation. For example,
assume that high staff turnover is noted as a project risk, r1. Based on past history and
management intuition, the likelihood, l1, of high turnover is estimated to be 0.70
percent, and the impact, x1, is projected at level 2.

To mitigate this risk, project management must develop a strategy for reducing
turnover. Among the possible steps to be taken are

 Meet with current staff to determine causes for turnover (e.g., poor working
conditions, low pay, and competitive job market).

 Mitigate those causes that are under our control before the project starts.

 Once the project commences, assume turnover will occur and develop techniques
to ensure continuity when people leave.

 Organize project teams so that information about each development activity is

widely dispersed.

 Define documentation standards and establish mechanisms to be sure that

documents are developed in a timely manner.

 Conduct peer reviews of all work (so that more than one person is "up to speed”).

 Assign a backup staff member for every critical technologist. As the project
proceeds, risk monitoring activities commence

In the case of high staff turnover, the following factors can be monitored:

 General attitude of team members based on project pressures.

 The degree to which the team has jelled.

 Interpersonal relationships among team members.

 Potential problems with compensation and benefits.

 The availability of jobs within the company and outside it.

In addition to monitoring these factors, the project manager should monitor the
effectiveness of risk mitigation steps. For example, a risk mitigation step noted here
called

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 188

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Risk management and contingency planning assumes that mitigation efforts

have failed and that the risk has become a reality. Continuing the example, the project
is well underway and a number of people announce that they will be leaving. If the
mitigation strategy has been followed, backup is available, information is
documented, and knowledge has been dispersed across the team.

In addition, the project manager may temporarily refocus resources (and

readjust the project schedule) to those functions that are fully staffed, enabling
newcomers who must be added to the team to “get up to speed.” Those individuals
who are leaving are asked to stop all wo and spend their last weeks in “knowledge
transfer mode.”

It is important to note that RMMM steps incur additional project cost. For
example, spending the time to "backup" every critical technologist costs money.

There are three issues of RMMM

 Actions to be taken in the event that mitigation steps have failed and the risk has
become a live problem
 Devise RMMP (Risk Mitigation Monitoring And Management Plan)

RMMM PLAN
1) Risk Avoidance(mitigation): Proactive planning for risk avoidance. This is
achieved by developing a plan for risk mitigation.

2) Risk Monitoring what factors can we track that will enable us to determine if the
risk is becoming more or less likely?
 Assessing whether predicted risk occur or not
 Ensuring risk aversion steps are being properly applied
 Collection of information for future risk analysis
 Determine which risks caused which problems

3) Risk Management what contingency plans do we have if the risk becomes a

reality?
 Contingency planning

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 189

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Each risk is documented individually by using a Risk Information Sheet. RIS

is maintained using a database system

Once RMMM has been documented and the project has begun, risk mitigation
and monitoring steps commence.

Figure 5.3
QUALITY MANAGEMENT
Quality Concepts
Variation control is the heart of quality control
Form one project to another, we want to minimize the difference between the
predicted resources needed to complete a project and the actual resources used,
including staff, equipment, and calendar time

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 190

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Quality
The American Heritage Dictionary defines quality as “a characteristic or attribute of
something.” As an attribute of an item, quality refers to measurable characteristics-
things we are able to compare to known standards such as length, color, electrical
properties, and malleability

When we examine an item based on its measurable characteristics, two kinds of

quality may be encountered: quality of design and quality of conformance.

Quality of design: Refers to characteristics that designers specify for the end product.
n software development, quality of design encompasses requirements, specifications,
and the design of the system

Quality of conformance is the degree to which the design specifications are followed
during manufacturing. It focuses on implementation. If the implementation follows
the design and the resulting system meets its requirements and performance goals,
conformance quality is high.

Robert Glass argues that a more “intuitive” relationship is in order:

User satisfaction = compliant product + good quality + delivery within budget and
schedule

At the bottom line, Glass contends that quality is important, but if the user isn’t
satisfied, nothing else really matters. “A product’s quality is a function of how much
it changes the world for the better.”

Quality Control
It involves the series of inspections, reviews, and test used throughout software
process to ensure each work product meets the requirement placed up on it.

Quality Assurance
It consists of a set of auditing and reporting functions that assess the effectiveness and
completeness of quality control activities. The goal of quality assurance is to provide
management with the data necessary to be informed about product quality, thereby
gaining insight and confidence that product quality is meeting its goals.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 191

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Cost of Quality
The cost of quality includes all costs incurred in the pursuit of quality or in
performing quality-related activities.
Quality costs may be divided into costs associated with prevention, appraisal, and
failure. Prevention costs include quality planning, formal technical reviews, test
equipment, training

Appraisal costs include activities to gain insight into product condition the “first time
through” each process. Examples of appraisal costs include in-process and
interprocess inspection, equipment calibration and maintenance and testing

Failure costs are those that would disappear if no defects appeared before shipping a
product to customers. Failure costs may be subdivided into internal failure costs and
external failure costs.

Internal failure costs are incurred when we detect a defect in our product prior to
shipment. Internal failure costs include rework,repair&• failure mode analysis

External failure costs are associated with defects found after the product has been
shipped to the customer. Examples of external failure costs are complaint resolution,
product return and replacement, help line support and warranty work

Software Quality Assurance

Software quality assurance (SQA) is the concern of every software engineer to reduce
cost and improve product time-to-market.
A Software Quality Assurance Plan is not merely another name for a test plan, though
test plans are included in an SQA plan.SQA activities are performed on every
software project.

Software quality is defined as Conformance to explicitly stated functional and

performance requirements, explicitly documented development standards, and
implicit characteristics that are expected of all professionally developed software.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 192

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

SQA Activities
Prepares an SQA plan for a project. The plan identifies
 evaluations to be performed
 audits and reviews to be performed
 standards that are applicable to the project
 procedures for error reporting and tracking
 documents to be produced by the SQA group
 amount of feedback provided to the software project team

Participates in the development of the project’s software process description.

The SQA group reviews the process description for compliance with organizational
policy, internal software standards, externally imposed standards (e.g., ISO-9001),
and other parts of the software project plan.

Reviews software engineering activities to verify compliance with the defined

software process.
Identifies, documents, and tracks deviations from the process and verifies that
corrections have been made.

Audits designated software work products to verify compliance with those

defined as part of the software process.
Reviews selected work products; identifies, documents, and tracks deviations; verifies
that corrections have been made and periodically reports the results of its work to the
project manager.

Ensures that deviations in software work and work products are documented
and handled according to a documented procedure.
Deviations may be encountered in project plan, process description, and applicable
standards

Records any noncompliance and reports to senior management. Noncompliance

items are tracked until they are resolved.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 193

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Software Reviews
Purpose is to find errors before they are passed on to another software engineering
activity.

What Are Reviews?

 a meeting conducted by technical people for technical people
 a technical assessment of a work product created during the software engineering
process
 a software quality assurance mechanism

Software engineers (and others) conduct formal technical reviews (FTRs) for software
quality assurance.

Using formal technical reviews (walkthroughs or inspections) is an effective means

for improving software quality

Formal Technical reviews

A FTR is a software quality control activity performed by software engineers
and others. The objectives are:
 To uncover errors in function, logic or implementation for any representation of
the software. To verify that the software under review meets its requirements.
 To ensure that the software has been represented according to predefined
standards. To achieve software that is developed in a uniform manner and
 To make projects more manageable.

In addition, FTR serves as a training ground enabling junior engineers to

observe different approaches to s/w analysis, design, and construction & testing

Review meeting
The Review meeting in a FTR should abide to the following constraints
 Review meeting members should be between three and five.
 Every person should prepare for the meeting and should not require more than two
hours of work for each person.
 The duration of the review meeting should be less than two hours.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 194

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

The focus of FTR is on a work product (ex requirement specification, a

detailed component design, a source code listing for a component). The individual
who has developed the work product i.e, the producer informs the project leader that
the work product is complete and that a review is required.

The project leader contacts a review leader, who evaluates the product for
readiness, generates copy of product material and distributes them to two or three
review members for advance preparation .Each reviewer is expected to spend between
one and two hours reviewing the product, making notes. The review leader also
reviews the product and establish an agenda for the review meeting.

The review meeting is attended by review leader, all reviewers and the
producer. One of the reviewer act as a recorder, who notes down all important points
discussed in the meeting.

The meeting (FTR) is started by introducing the agenda of meeting and then
the producer introduces his product. Then the producer “walkthrough” the product,
the reviewers raise issues which they have prepared in advance. If errors are found the
recorder notes down.

At the end of the review, all attendees of the FTR must decide whether to (1)
accept the product without further modification, (2) reject the product due to severe
errors(once corrected, another review must be performed), or (3) accept the product
provisionally (minor errors have been encountered and must be corrected, but no
additional review will be required). The decision made, all FTR attendees complete a
sign- off, indicating their participation in the review and their concurrence with the
review team's findings.

Review Reporting and record keeping

During the FTR, a reviewer (recorder) records all issues that have been raised
 A review summary report answers three questions
 What was reviewed?
 Who reviewed it?
 What were the findings and conclusions?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 195

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Review summary report is a single page form with possible attachments The
review issues list serves two purposes
 To identify problem areas in the product
 To serve as an action item checklist that guides the producer as corrections are
made

It is important to establish a follow-up procedure to ensure that items on the

issues list have been properly corrected. One approach is to assign the responsibility
for follow-up to the review leader.

Review Guidelines
 Review the product, not the producer
 Set an agenda and maintain it
 Limit debate and rebuttal
 Enunciate problem areas, but don’t attempt to solve every problem noted
 Take written notes
 Limit the number of participants and insist upon advance preparation.
 Develop a checklist for each product i.e likely to be reviewed
 Allocate resources and schedule time for FTRS
 Conduct meaningful training for all reviewer
 Review your early reviews

Sample-Driven Reviews
The lon and his colleagues suggest a sample-driven review process in which
samples of all software engineering work products are inspected to determine which
work products are most error prone.SDRs attempt to quantify those work products
that are primary targets for full FTRs.
To accomplish this …
1) Inspect a fraction ai of each software work product, i. Record the number of
faults, fi found within ai.
2) Develop a gross estimate of the number of faults within work product i by
multiplying fi by 1/ai.
3) Sort the work products in descending order according to the gross estimate of the
number of faults in each.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 196

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

4) Focus available review resources on those work products that have the highest
estimated number of faults.

Statistical Software Quality Assurance

Statistical quality assurance reflects a growing trend throughout industry to
become quantitative about quality. For software, statistical quality assurance implies
the following steps:
1) Information about software defects is collected and categorized.
2) An attempt is made to trace each defect to its underlying cause (e.g., non-
conformance to specifications, design error, violation of standards, poor
communication with the customer).
3) Using the Pareto principle (80 percent of the defects can be traced to 20 percent of
all possible causes), isolate the 20 percent (the "vital few").
4) Once the vital few causes have been identified, move to correct the problems that
have caused the defects.

Six Sigma for Software Engineering

Six sigma is the most widely used strategy for statistical software quality assurance
 The term “six sigma” is derived from six standard deviations—3.4 instances
(defects) per million occurrences—implying an extremely high quality standard.
 The Six Sigma methodology defines three core steps:
 Define customer requirements and deliverables and project goals via well-defined
methods of customer communication
 Measure the existing process and its output to determine current quality
performance (collect defect metrics)
 Analyze defect metrics and determine the vital few causes.
 Improve the process by eliminating the root causes of defects.
 Control the process to ensure that future work does not reintroduce the causes of
defects.

If new processes are being developed

 Design each new process to avoid root causes of defects and to meet customer
requirements
 Verify that the process model will avoid defects and meet customer requirements

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 197

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Software Reliability
Software reliability is defined as the probability of failure free operation of a
computer program in a specified environment for a specified time.

To illustrate, program X is estimated to have a reliability of 0.96 over eight

elapsed processing hours.

In other words, if program X were to be executed 100 times and require eight
hours of elapsed processing time (execution time), it is likely to operate correctly
(without failure) 96 times out of 100. Can be measured directly and estimated using
historical and developmental data

Measures of Reliability and Availability

If we consider a computer-based system, a simple measure of reliability is
mean-time-between-failure (MTBF), where
MTBF = MTTF + MTTR

The acronyms MTTF and MTTR are mean-time-to-failure and mean-time-to-

repair, respectively.

Many researchers argue that MTBF is a far more useful measure than
defects/KLOCor defects/FP. Stated simply, an end-user is concerned with failures, not
with the total error count.

Software availability is the probability that a program is operating according

to requirements at a given point in time and is defined as
Availability = [MTTF/(MTTF + MTTR)] * 100%

The MTBF reliability measure is equally sensitive to MTTF and MTTR. The
availability measure is somewhat more sensitive to MTTR, an indirect measure of the
maintainability of software

Software Safety
Software safety is a software quality assurance activity that focuses on the
identification and assessment of potential hazards that may affect software negatively
and cause an entire system to fail.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 198

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

If hazards can be identified early in the software engineering process, software

design features can be specified that will either eliminate or control potential hazards.
Analysis techniques such as fault tree analysis, real-time logic or petri net models can
be used to predict the chain of events that can cause hazards and the probability that
each of the events will occur to create the chain.
Although
ISO 9000 Quality Standards
Software reliability and software safety are closely related to one another, it is
important to understand the subtle difference between them. Software reliability uses
statistical analysis to determine the likelihood that a software failure will occur.
However, the occurrence of a failure does not necessarily result in a hazard or mishap.
Software safety examines the ways in which failures result in conditions that can lead
to a mishap.

A quality assurance system may be defined as the organizational structure,

responsibilities, procedures, processes, and resources for implementing quality
management

Quality assurance systems are created to help organizations ensure their

products and services satisfy customer expectations by meeting their specifications.
ISO 9000 describes quality assurance elements in generic terms that can be applied to
any business regardless of the products or services offered

IS0 9001:200 Is the quality assurance standard that applies to software

engineering. The standard contains 20 requirements that must be present for an
effective quality assurance system. Because the ISO 9001:2000 standard is applicable
to all egg disciplines a special set of ISO guidelines have been developed.

The requirements delineated by ISO 9001:2000 address topics such as

management responsibility, quality system, contract review, design control, document
and data control, product identification and traceability, process control, inspection
and testing, corrective and preventive action, control of quality standards, internal
quality audits, training, servicing and statistical techniques. For a software
organization to become registered to IS0 9001:200,it must establish policies and
procedures to address each of the requirements noted and then able to demonstrate
that these policies and procedures are being followed.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 199

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

TUTORIAL QUESTIONS
UNIT I
1) Define Software Engineering.
2) What is a Process Framework?
3) How the Process Model differ from one another?
4) Explain waterfall model? Write out the reasons for the Failure of Water Fall Model?
5) Explain RAD model? What are the Drawbacks of RAD Model?

UNIT II
1) Explain SDLC
2) What is Structured Analysis? Explain all the tools of structured Analysis?
3) What are the Objectives of Requirement Analysis?
4) Explain design Process & also it’s various methods?
5) Define System Context Diagram [SCD]?

UNIT III
1) Define Refactoring.
2) What are the Five Types of Design classes?
3) What are the Different types of Design Model? Explain.
4) List out the Different elements of Design Model?
5) What are the Types of Interface Design Elements?

UNIT IV
1) Define Smoke Testing?
2) What are the Attributes of Good Test?
3) Define White BoxTesting.
4) Define Basic PathTesting.
5) Define the terms :
a) Graph Matrices
b) Connection Matrices.

UNIT V
1) How do we define Software Quality?
2) Define Software Reliability?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 200

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

3) List and explain different types of testing done during the testing phase?
4) What is change management?
5) What is generalization? Give an example of generalization

ASSIGNMENT QUESTIONS
UNIT I
1. Explain software Engineering? Explain the software engineering layers?
2. Explain different software applications?
3. Explain changing nature of software indetail?
4. Explain staged model in CMMI?
5. Explain PSP and TSP?

UNIT II
1. Identify and briefly describe four types of requirements that may be 1 defined for
computer based system?
2. List out plausible user requirements for the following functions a) cash dispensing
function in a bank ATM 2 b) spelling check and correcting function in a word processor?
3. Suggest how an engineer responsible for drawing up a system requirements specification
might keep track of the relationship 3 between functional and non-functional
requirements?
4. Suggest who might be stakeholders in a university student record system. Explain why it
is almost inevitable that the requirements of 4 different stakeholders will conflict in some
way?
5. Explain who should be involved in requirements review? Draw a process model showing
how a requirements review might be 5 organized?

UNIT-III
1. Explain why design is important in design engineering?
2. Discuss analysis and design model?
3. Describe quality attributes and its guidelines?
4. List the design concepts?
5. Justify the importance of refactoring?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 201

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT-IV
1. Provide a few examples that illustrate why response time variability can be an Issue.
2. Develop two additional design principles “place the user in control”?
3. Develop two additional design principles “make the interface 3 consistent”?
4. Develop a complete test strategy for the safe home system. Document 4 it in a
Specification
5. Provide examples for unit testing?

UNIT-V
1. Quality and reliability are related concepts but are fundamentally Apply 8 different in
number of ways. Discuss them?
2. Explain you have been given the responsibility for improving Apply 8 quality of
software across your organization. What is the first thing that you should do? what’s
next?
3. Some people argue that an FTR should assess programming style as Apply 8 well as
correctness is this a good idea? Discuss why?
4. Demonstrate is it possible to assess the quality of software if the Apply 9 customer keeps
changing what it is supposed to do?
5. Create a risk table for the project that if you are the project manager Apply 9 for a major
software company. you have been asked to lead a team that’s developing “next
generation “word- processing software?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 202

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

OBJECTIVE QUESTIONS
UNIT I
1. The goal of software engineering is
a. Quality b. Productivity c. Cost effective d. All
2. What is an example of system software.
a. Compilers b. Editors c. File management utilities d. All
3. Model can be called as “meta model” in the development.
a. Prototype b. RAD c. Life cycle d. Incremental.
4. During the software engineering maintenance phase focuses on
a. What b. How c. Change d. None
5. What is an example for object oriented languages.
a. C++ b. C c. Pascal d. COBOL
6. Embedded software resides in ---------------
a. RAM b. ROM c. Hard disk d. None.
7. Multiprogramming and multiuser systems are introduced at--------------------------- era.
a. First era b. Second era c. Third era d. Fourth era.
8. What is the measure for maintainability?
9. Acronym for CASE is
10. Software metrics are direct measures of software.
11. is an important characteristics of high quality software component.
12. process translates requirements into a representation of software.
13. According to generic view of software engineering focuses on .
14. According to generic view of software engineering phase focuses on .
15. Acronym for CMMI .

UNIT II
1) Which one of these belongs to integration testing in the OO context?
a. Unit testing
b. Regression testing
c. Sandwich testing
d. Thread-based testing

2) In which elicitation process the developers discuss with the client and end users and
know their expectations from the software?
a. Requirement gathering
b. Organizing requirements
c. Negotiation & discussion
d. Documentation

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 203

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

3) If requirements are easily understandable and defined then which model is best
suited?
a) Spiral model
b) Waterfall model
c) Prototyping model
d) None of the above

4) Which Software-end factors affecting maintenance Cost?

a) Structure of Software Program
b) Programming Language
c) Dependence on external environment
d) All mentioned above
e) None of the above

5) Software quality assurance is an umbrella activity.

a) True
b) False

6) Software process and improvement are assessed by .

a) ISO 9000
b) ISO 9001
c) SPICE (ISO/IEC15504)
d) Both B and C

7) CASE Tool stands for.

a) Computer Aided Software Engineering
b) Component Aided Software Engineering
c) Constructive Aided Software Engineering
d) Computer Analysis Software Engineering

8) Software is defined as .
a) Instructions
b) Data Structures
c) Documents
d) All of the above

9) During security testing the tester plays the role of the individual who desires t
a) Penetrates the system
b) Penetrates the listener
c) Both A & B
d) None of the above

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 204

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

10) Which of the following is not a section in the standard for SQA plans recommended
by IEEE?
a) Budget
b) Time
c) People
d) None of the above

11) Which box specifies the behavior of a system or a part of a system?

a) State box
b) Clear box
c) Black box
d) None of the above

12) FAST stands for

a) Facilitated Application SoftwareTechnique.
b) Functional Application Software Technique.
c) Facilitated Application Specification Technique.
d) None of the above.

13) Which may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software?
a) Time estimation
b) Effort estimation
c) Cost estimation
d) Software size estimation

14) SDLC Models are adopted as per requirements of development process. It may vary
Software-to-software to ensuring which model is suitable.
a) True
b) False

15) The always growing and adapting nature of software hugely depends upon the
environment in which user works in .
a) Cost
b) Dynamic Nature
c) Quality Management
d) Scalability

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 205

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT III
1. Which of these states the goal of engineering designanalysis?
a) To understand an engineering design problem
b) To provide an solution for a given problem
c) All of the mentioned
d) None of the mentioned

2. What methods can be followed if designers are out of good SRS or engineering
design ?
a) They must do whatever part of product design which remains undone
b) Various approaches and techniques are to be followed to complete
c) All of the mentioned
d) None of the mentioned

3. Why is Modelling one of the best way to carry out analysis ?

a) During analysis, It serves as a good test for understanding
b) Provides further documentation for input to design resolution
c) All of the mentioned
d) None of the mentioned

4. Engineering design activities consists of which of the following ?

a) Studying the SRS
b) Producing new models of the problem
c) Product design models
d) All of the mentioned

5. A generic software engineering design follows which of the activities ?

a) Analysis
b) Architectural Design
c) Finalize Design
d) Analysis & Architectural Design

6. Architectural design stage include which of the following activity ?

a) Generate/Improve detailed design alternatives
b) Select architecture
c) Finalize Design
d) All of the mentioned

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 206

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

7. Detailed design stage include which of the following activity ?

a) Generate / Improve candidate architectures
b) Evaluate candidate architecture
c) Finalize Design
d) None of the mentioned

8. What is Analysis model ?

a) Understanding of design problem
b) Representation of design problemsolution
c) Representation of designproblem
d) All of the mentioned

9. Which of the following is true ?

a) A class model is representation of objects in a problem or a software solution
b) A object model is representation of classes in a problem or a software solution
c) All of the mentioned
d) None of the mentioned

10. Which of the following is true ?

a) Class Diagram are graphical form of class models
b) Object Diagram are graphical forms of object models
c) All of the mentioned
d) None of the mentioned

11. Which of these are types of class model used in object oriented analysis ?
a) Analysis Class models/ Conceptual Models
b) Design Class Models
c) Implementation Class Models
d) All of the mentioned

12. Which of the following represents the use of Conceptual models during product
design?
a) Understanding the problem design
b) Setting Data Requirements
c) Validating Requirements
d) All of the mentioned

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 207

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

13. Which of the following represents the use of Conceptual models during
engineering design?
a) Understanding product design
b) Under Girding Engineering Modelling
c) All of the mentioned
d) None of the mentioned

14. What are Design Class Models ?

a) They show classes in a software system
b) They represents attributes, operations, association in abstraction from language
c) They show implementation details
d) All of the mentioned

15. Conceptual models are useful for which of the following reasons ?
a) Understanding problem design
b) Data Requirements and Product design
c) Validating requirements
d) All of the mentioned

UNIT IV
1. Which of the following activities is part in the clean room process?
a) Increment planning b) Requirements gathering
c) Statistical use testing d) All of the above

2. The clean room strategy is based on the software process model.

a) Evolutionary b) incremental
c) Revolutionary d) spiral

3. The clean room strategy relieson

a) Exhaustive testing b) extensive unit testing of all modules
c) Tests that exercise the software as it is really used
d) white box testing strategies

4. Use of formal program correctness proofs as part of the clean room process
eliminates the need to do any testing for software defects.
a) True b) False

6. In clean room software engineering a "box" encapsulates some system aspect at a

particular level of detail.
a) True b) False

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 208

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

7. This box specification describes an abstraction, stimuli, and response.

a) black box b) clear box
c) state box d) white box

8. This box specification describes the architectural design for some system
component.
a) black box b) clear box
c) state box d) white box

9. This box specification is closely aligned with procedural design and structured
programming.
a) black box b) clear box
c) state box d) white box

10. Which of the following is not an advantage of using rigorous correctness verification
of each refinement of the clear box design.
a) improves performance of code b) produces better code than unit testing
c) reduces verification effort d) results in near zero defect levels

11. Statistical use testing relies on probability distributions based on

a) mixture of control structures used in the program
b) order in which the module execute
c) the way software will actually be used
d) user interface design standards

12. Certification of an increment is complete once it has passed the formal verification
process.
a) True b) False

13. Which of the following models is part of the clean room certification process?
a) component model b) sampling model
c) both a and b d) none of the above

14. In component-based software engineering, the development team examines the

requirements to see which are amenable to composition, rather than
construction, before beginning detailed design tasks.
a) True b) False

15. Which of the following is not one of the CBSE activities that take place for
requirements that can be addressed with commercial off-the-shelf (COTS)
components?
a) component adaptation b) component composition
c) component design d) component qualification

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 209

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT – V

1. Which of the following is not an example of a business process?

A) designing a new product
B) hiring an employee
C) purchasing services
D) testing software

2. Which of the following is not a principle that should guide business process
reengineering?
a) capture data at each source
b) fully re document legacy processes
c) organize around outcomes
d) put decision point where work is performed

3. Business process reengineering has no start or end—it is an evolutionary process.

a) True b) False

4. Business process reengineering is just another silver bullet fad with no real
benefits to anyone.
a) True b) False

5. How much of software maintenance work involves fixing errors?

a) 20 percent b) 40 percent
c) 60 percent d) 80 percent

6. Which of the following activities is not part of the software reengineering process
model?
a) forward engineering b) inventory analysis
c) prototyping d) reverse engineering

7. The software reengineering process model includes restructuring activities for

which of the following work items?
a) code b) documentation
c) data d) all of the above
8. Which of the following is not an issue to consider when reverse engineering?
a) abstraction level b) completeness
c) connectivity d) directionality

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 210

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

9. Reverse engineering of data focuses on

a) database structures b) internal data structures
c) both a and b d) none of the above

10. The first reverse engineering activity involves seeking to understand

a) data b) processing
c) user interfaces d) none of the above

11. Reverse engineering should precede the reengineering of any user interface.
a) True b) False

12. Which of these benefits can be achieved when software is restructured?

a) higher quality programs
b) reduced maintenance effort
c) software easier to test
d) all of the above

13. Code restructuring is the most important activity performed as part of software
reengineering.
a) True b) False

14. Which of these is not an example of data redesign?

a) data analysis b) data name rationalization
c) data record standardization d) none of the above

15. Forward engineering is not necessary if an existing software product is producing

the correct output.
a) True b) False

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 211

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT WISE QUESTIONS

UNIT - I
1. Explain the evolving role of software?
2. Define software and explain the various characteristics of software?
3. Describe “Software myth”? Discuss on various types of software myths and the true
aspects of these myths?
4. Explain software Engineering? Explain the software engineering layers?
5. Explain in detail CMM?
6. Describe with the help of the diagram discuss in detail waterfall model.
Give certain reasons for its failure?
7. Explain briefly on (a) the incremental model (b) The RAD Model?
8. Explain the Spiral model in detail?
9. Describe With the help of the diagram explain the concurrent development model?
10. Explain unified process? Elaborate on the unified process work products?
11. Explain specialized process models?
12. Explain different software applications?
13. Explain the paradigms do you think would be most effective? Why?
14. Explain product and process are related?
15. Explain personal and team process models?

UNIT - II
1. What is system requirement? How would you specify them?
2. Discuss about principal requirements engineering activities and their relationships.
3. Define a scenario. Write a sample use case scenario for an article downloading in the
library system.
4. Explain state machine model with a suitable example?
5. Discuss how feasibility studies are important in requirement engineering process?
6. Explain SRS document and explain along with its contents?
7. Explain Behavioral models, Data models and Object models?
8. Explain in which circumstances would you recommend using structured methods for
system development?
9. Explain SRS document and explain along with its contents?
10. Explain interface specification in detail?
11. Discuss how requirements are felicitated and validated in software project?
12. Discuss how feasibility studies are important in requirement engineering process?
13. Demonstrate class hierarchy for library by using interface specification?
14. Explain inheritance model?
15. Explain state machine model with a suitable example?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 212

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

UNIT-III
1. Write short notes on architecture patterns?
2. Compare function oriented and object oriented design?
3. Define top-down and bottom-up design model?
4. Write short notes on coupling?
5. List out the steps for conducting component level design?
6. Write short notes on cohesion?
7. Explain a two level process? Why should system design be finished before the detailed
design, rather starting the detailed design after the requirements specification? Explain
with the help of a suitable example
8. Discuss briefly the following fundamental concepts of software design:
a) Abstraction
b) Modularity
c) Information hiding
9. Explain briefly the following:
a) Coupling between the modules,
b) The internal Cohesion of a module
10. Elaborate model for the design?
11. Discuss architectural styles and patterns?
12. Explain with a neat diagram of architecturaldesign?

UNIT-IV
1. Explain about the importance of test strategies for conventional software?
2. Discuss black box testing in a detailed view?
3. Compare black box testing with white box testing?
4. Compare validation testing and system testing?
5. Discuss software quality factors? Discuss their relative importance?
6. Discuss an overview of qualitymetrics?
7. Explain should we perform the Validation test – the software developer or the software
user? Justify your answer?
8. Explain about Product metrics?
9. Explain about Metrics for maintenance?
10. Explain in detail about Software Measurement?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 213

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

11. Explain about Metrics for software quality?

12. Explain strategic approach to software testing?
13. Describe test strategies for conventional software?
14. Describe validation testing?
15. Write long notes on system testing?
16. Demonstrate art of debugging?
17. Discuss a framework for product metrics?
18. Demonstrate metrics for analysis model?
19. List the metrics for the design model?
20. Describe metrics for source code and for testing?

UNIT-V
1. Explain about software risks?
2. Elaborate the concepts of Risk management Reactive vs. Proactive Risk strategies?
3. Explain about RMMM Plan?
4. Explain about Quality concepts?
5. Explain software quality assurance?
6. Explain about formal technical reviews?
7. Explain in detail ISO 9000 quality standards?
8. Discuss risk refinement?
9. Compare reactive with proactive risk strategies?
10. Discuss software reliability?
11. Briefly explain about formal approaches to SQA?
12. Demonstrate statistical SQA?
13. Define software reliability along with its terms?
14. Explain risk projection in detail?
15. Explain seven principals of risk management?
16. Explain software reviews in brief?
17. Explain six sigma for software engineering?
18. Explain quality management with their terms?
19. Demonstrate risk identification?
20. Describe developing a risk table?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 214

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

PREVIOUS EXTERNAL QUESTION PAPERS

Code No: 125EM R15
JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY HYDERABAD
B. Tech III Year I Semester Examinations, November/December -
2017 SOFTWARE ENGINEERING
(Common to CSE, IT)
Time: 3 hours Max. Marks: 75
Note: This question paper contains two parts A and B.
Part A is compulsory which carries 25 marks. Answer all questions in Part A. Part B consists
of 5 Units. Answer any one full question from each unit. Each question carries 10 marks and
may have a, b, c as sub questions.

PART – A
(25 Marks)
1. a) Distinguish between Software products and Software services. [2]
b) Explain Software Crisis [3]
c) Define an Interface. [2]
d) Explain about data models. [3]
e) What are the golden rules for User Interface Design? [2]
f) Explain the Design concept coupling. [3]
g) Define Testing. [2]
h) List the metrics for Design model. [3]
i) Define Risk Refinement. [2]
j) Define Software reliabilty. [3]

PART – B
(50 arks)
2. a) What is a Legacy Software? Explain.
b) Explain the Software Process Framework [5+5]
OR
3. a) Explain the various software myths.
b) Explain the working of specializedprocess model [5+5]

2. a) Explain the structure of Software Requirements document.

b) What are the feasibility studies for requirements engineering process? [5+5]
OR
3. Explain the following system models: [5+5]
a) Object Models
b) Structured methods.

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 215

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

4. Explain the following five Component characteristics: [10]

a) Standardized
b) Independent
c) Composable
d) Deployable
e) Documented.
OR
7. a) Explain the basic elements of a component model with suitable diagram.
b) Explain the Component Based Software Engineering (CBSE). [5+5]

8. a) Explain the methods of System Testing.

b) Explain the metrics for Analysis Model. [5+5]
OR
9. a) Explain metrics for Software Quality.
b) Describe test strategies for Conventional Software. [5+5]

10. a) Explain Software Risks.

b) Describe the methods for Risk Identification. [5+5]
OR
11. a) Explain the use of Software Reviews.
b) Describe the methods for Risk Projection. [5+5]

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 216

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Code No: 115EM R13

JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY HYDERABAD
B. Tech III Year I Semester Examinations, March
- 2017 SOFTWARE ENGINEERING
(Common to CSE, IT)
Time: 3 hours Max. Marks: 75
Note: This question paper contains two parts A and B.
Part A is compulsory which carries 25 marks. Answer all questions in Part A. Part B consists of 5 Units. Answer
any one full question from each unit. 10 marks and may have a, b, c as sub questions.
Each question carries

PART - A
(25 Marks)
1. a) What are the merits of incremental model? [2]
b) What are the fundamental activities of a software process? [3]
c) Differentiate ERD and DRD. [2]
d) What are non functional requirements? [3]
e) Define design process. [2]
f) List the principles of a software design. [3]
g) Distinguish between verification and validation. [2]
h) Write about drivers and stubs. [3]
i) Give a note on the various estimation techniques. [2]
j) Define maintenance. What are the types of software maintenance? [3]

PART - B
(50 arks)

2. a) Define the term Software. Describe its various characteristics.

b) Elaborate on the changing nature of software in detail. [5+5]
OR
3. a) Explain software development life cycle. Discuss various activities
during SDLC.
b) What are various myths about software? [5+5]

4. Give an overview of various system models. [10]

OR
5. a) Discuss about principal requirements engineering activities
and their relationships.
b)Explain how a software requirements document is structured. [5+5]

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 217

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

6. a) Distinguish between coupling and cohesion? How do they effect software design?
b) For a Case study of your choice show the architectural and component design.
[5+5]
OR
7. List and explain different kinds of architecture styles and patterns. [10]

8. What is black box testing? What is boundary value Analysis? Explain the technique
specifying rules and its usage with the help ofan example [10]
OR
9. a) Define unit testing. Explain about unit testing considerations and procedures.
b) What is equivalence class partitioning? List rules used to define valid and invalid
equivalence classes. Explain the technique using examples. [5+5]

10. a) What is the purpose of Delphi method? State advantages and disadvantages of the
method.
b) Explain the COCOMO model for estimation. [5+5]
OR
11. What is software configuration management? Explain various aspects of the
configuration management. [10]

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 218

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Code No: 115EM R13

JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY HYDERABAD
B. Tech III Year I Semester Examinations, November/December
- 2016 SOFTWARE ENGINEERING
Time: 3 hour Max. Marks: 75
Note: This question paper contains two parts A and B.
Part A is compulsory which carries 25 marks. Answer all questions in Part A. Part B consists of 5 Units. Answer
any one full question from each unit. Each question carries 10 marks and may have a, b, c as sub questions.
PART A

1. a) What is legacy software? Explain. [2]

b) What are the advantages of unified process? [3]
c) Write the purpose of context model. [2]
d) What is the significance of feasibility study? [3]
e) What is the use of interface analysis? Explain. [2]
f) What do you mean by software design quality? Explain. [3]
g) Differentiate between verification and validation. [2]
h) What is regression testing? Give example. [3]
i) Define software reliability. [2]
j) What is the importance of software reviews? [3]

PART B
(50 Marks)
2. a) Discuss about the changing nature of software
b) Explain spiral model with its merits and demerits. [5+5]
OR
3. a) Discuss in brief about different software myths and their consequences.
b) Explain CMMI model with a neat sketch.
[5+5]
4. a) Differentiate between functional and non-functional requirements.
b) List and explain the object models in brief. [5+5]
OR
5. a) What are the activities of requirements elicitation and analysis? Explain.
b) Discuss about different structured methods used in software development.
[5+5]
6. a) Explain the process of mapping dataflow into software architecture.
b) List the golden rules of user interface design. [5+5]
OR
7. a) Discuss about pattern based software design in detail.
b) Define and explain about different types of cohesion. [5+5]

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 219

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

8. a) Describe the framework for software product metrics.

b)Differentiate between Black box and White box testing. [5+5]
OR
9. a) What are the metrics used for software maintenance? Discuss.
b) Briefly discuss about Integration testing strategies. [5+5]

10. a) Differentiate between Reactive Vs Proactive risk strategies.

b) What is the significance formal technical review? Explain. [5+5]
OR
11. a) Write a detailed note on ISO 9000 quality standards.
b) What types of risks occur during software development? Discuss. [5+5]

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 220

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

Code No: 115EM R13

JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY HYDERABAD
B.Tech III Year I Semester Examinations, February/March
- 2016 SOFTWARE ENGINEERING
(Common to CSE, IT)
Time: 3 hour Max. Marks: 75
Note: This question paper contains two parts A and B.
Part A is compulsory which carries 25 marks. Answer all questions in Part A. Part B consists of 5 Units.
Answer any one full question from each unit. Each question carries 10 marks and may have a, b, c as sub
questions.
Part- A
(25 Marks)
1. a) Distinguish between software process and project. [2]
b)Discuss about changing nature of software. [3]
c) What is meant by system requirements? [2]
d) Explain about context models. [3]
e) Write brief notes on data design. [2]
f) Write about interface design evaluation. [3]
g) What is meant by debugging? [2]
h) What is meant by software measurement? [3]
i) What is meant by software reliability? [2]
j) Discuss the reactive risk strategy. [3]

Part- B
(50 Marks)
2. State and explain various software myths. [10]
OR
3. Explain about specialized process models. [10]

4. Explain clearly about software requirements document. [10]

OR
5. State and explain various aspects in requirements validation process. [10]

6. Discuss about mapping dataflow into software architecture. [10]

OR
7. Explain about conducting component level design. [10]

8. Discuss about metrics for design model and source code. [10]
OR
9. Explain clearly about metrics for software quality. [10]

10. Explain about formal technical reviews. [10]

OR
11. Explain about risk projection and risk management. [10]

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 221

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

SAMPLE INTERNAL PAPERS

MALLAREDDY ENGINEERING COLLEGE FOR WOMEN AUTONOMOUS
INSTITUTION
UGC, GOVT. OF INDIA DEPARTMENT OF CSE & IT MID EXAM
SUB: SOFTWARE ENGINEERING CLASS/SEM/BRACH: III-I CSE & IT
DATE: SECTION: A, B, C and D
TIME: 90 min MARKS: 40 marks

PART-A
Answer All the following Questions (5*2=10 M)
1. Define Software Engineering and list out the seven broad categories of software?
2. Write short notes on Generic Process Framework?
3. Define Software Requirement and list out the types of requirements?
4. Explain View Points and types of View Points?
5. Define Design Engineering?

PART-B
Answer the following Questions (3*10=30M)
1. a) List out and Explain CMMI levels?
(OR)
b) Explain SPIRAL model with neat diagram?

2. a) Explain UNIFIED PROCESS in detail with neat diagram?

(OR)
b) Explain REQUIREMENTS ENGINEERING PROCESS in detail?

3. a) List out and Explain SYSTEM MODELS?

(OR)
b) Explain Design Guidelines and Design Principles?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 222

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

MALLA REDDY ENGINEERING COLLEGE FOR WOMEN AUTONOMOUS

INSTITUTION-UGC, GOVT. OF INDIA DEPARTMENT OF CSE & IT
MID EXAM
SUB: SOFTWARE ENGINEERING CLASS/SEM/BRACH: III-I CSE & IT
DATE: 09-11-2016 SECTION: A, B, C and D
TIME: 90MIN MARKS: 40 marks

PART-A
Answer All the following Questions (5*2=10M)
1. Define a) COHESION b) COUPLING?
2. Define a) ALPHA TESTING b) BETA TESTING?
3. Define REFACTORING?
4. Write a brief note on RISKASSESSMENT?
5. Define QUALITY OF CONFORMANCE?

PART-B
Answer the following Questions (3*10=30M)
1. a) Elaborate on DESIGN QUALITY?
(OR)
b) Explain with a neat diagram translating ANALYSIS MODEL TO DESIGN MODEL?

2. a) Explain about TOP-DOWN INTEGRATION in detail?

(OR)
b) Differentiate between WHITE BOX and BLACK BOX TESTING?

3. a) Explain FORMAL TECHNICAL REVIEWS in detail?

(OR)
b) Explain SOFTWARE QUALITY CONTROL?

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 223

Downloaded by Arsh Khan ([email protected])

 lOMoARcPSD|32859433

Software Engineering Department of CSE

REFERENCES, JOURNALS, E-LINKS AND WEBSITES

REFERENCES
 Abran, Alain; Moore, James W.; Bourque, Pierre; Dupuis, Robert; Tripp, Leonard L.
(2004). Guide to the Software Engineering Body of Knowledge. IEEE. ISBN 0-7695-
2330-7.
 Sommerville, Ian (2008). Software Engineering (7 ed.). Pearson Education. ISBN 978-
81-7758-530-8. Retrieved 10 January 2013

JOURNALS:
 International Journal Of Software Engineering
 The Journal Of Defense Software Engineering
 Advances in Software Engineering

WEBSITES:
 www.pentagon2000.com http://www.sei.cmu.edu/
 http://iansommerville.com/software-engineering-book/
 http://www.advsofteng.com/about.html

E-LINKS
 Guide to the Software Engineering Body of Knowledge
 The Open Systems Engineering and Software Development Life Cycle Framework Open
SDLC.org the integrated Creative Commons SDLC
 Software Engineering Institute Carnegie Mellon
 Learn Software Engineering Software Engineering Society

Mallareddy Engineering College For Women (Autonomous Institution, UGC-Govt. of India) Page 224

Downloaded by Arsh Khan ([email protected])