UNIT-II

Agile Development: What is Agility, Agility and the cost of change, What
is an Agile Process, Agile Process Extreme programming, SCRUM,
Dynamic Systems Development Method, Agile Unified Process.

Requirements Engineering: Establishing the ground work, Eliciting

requirements, Developing use cases, Building the Analysis model,
Negotiating Requirements, Requirement Monitoring, Validating
Requirements.

Design concepts: The Design Process, Design Concepts, The Design

Model.
 Agile Software Development

•In the modern economy, it is often difficult or impossible to predict

how a software system will evolve as time passes.

•Market conditions change rapidly, end-user needs evolve, and new

competitive threats emerge without warning.

•In many situations, you won’t be able to define requirements fully

before the project begins.
•You must be agile enough to respond to a changing business
environment And change is expensive.Particularly if it is
uncontrolled or poorly managed.

•One of the most compelling characteristics of the agile approach is its

ability to reduce the costs of change throughout the software process.
 What is Agility?

• Effective response to change.

• Effective communication among all stakeholders

• Drawing the customer onto the team;eliminate the “us and

them” attitude.
• Organizing a team so that it is in control of the work performed.

• Rapid, incremental delivery of software holders

 What is “Agility”?
•In Jacobson’s view, the pervasiveness of change is the primary driver for
agility.

•Software engineers must be quick on their feet if they are to

accommodate the rapid changes that Jacobson describes.

•An agile process reduces the cost of change because software is released in
increments and change can be better controlled within an increment

•“Agility is dynamic, content specific, aggressively change embracing, and

growth oriented.”
Agility and the Cost of Change
•A well-designed agile process “flattens” the cost of change curve

•Allowing a software team to accommodate changes late in a

software project without dramatic cost and time impact.

•You’ve already learned that the agile process

encompasses incremental delivery.

•When incremental delivery is coupled with other agile practices

such as continuous unit testing and pair programming the cost
of making a change is attenuated.
Agility and the Cost of Change
 An Agile Process
• It is difficult to predict in advance which software
requirements will persist and which will change. It is equally
difficult to predict how customer priorities will change as
the project proceeds.

• For many types of software, design and construction are

interleaved. That is, both activities should be performed in
tandem so that design models are proven as they are
created. It is difficult to predict how much design is
necessary before construction is used to prove the design.

• Analysis, design, construction, and testing are not as

predictable (from a planning point of view) as we might like
• How do we create a process that can manage
unpredictability?

An agile process, therefore, must be adaptable.

An agile software process must adapt incrementally

• Software increments (executable prototypes or portions of an

operational system) must be delivered in short time periods so
that adaptation keeps pace with change (unpredictability).

• This iterative approach enables the customer to evaluate the

software increment regularly, provide necessary feedback to
the software team, and influence the process adaptations that
are made to accommodate the feedback
1.Agility Principles
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.

3. Deliver working software frequently, from a couple of weeks

to a couple of months, with a preference to the shorter
timescale.

4. Business people and developers must work together daily

throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done.

6. The most efficient and effective method of conveying

information to and within a development team is face–to–face
conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace
indefinitely.
9.Continuous attention to technical excellence and good design
enhances agility.

10.Simplicity – the art of maximizing the amount of work not done

– is essential.

11.The best architectures, requirements, and designs emerge from

self–organizing teams.

12. At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly.
 2.The Politics of Agile Development

• Traditional methodologists are a bunch of stick-in-the-muds who’d

rather produce flawless documentation than a working system that
meets business needs.”

• Even within the agile school itself, there are many proposed process
models each with a subtly different approach to the agility problem.

• Within each model there is a set of “ideas” (agilists are loath to call
them “work tasks”) that represent a significant departure from
traditional software engineering.
• And yet, many agile concepts are simply adaptations of good software
engineering concepts.

• Bottom line: there is much that can be gained by considering the best
of both schools and virtually nothing to be gained by denigrating either
approach.
 3.Human Factors
• Competence - encompasses innate talent, specific software-related
skills, and overall knowledge of the process that the team has chosen
to apply. Skill and knowledge of process can and should be taught to all
people who serve as agile team members.

• Common focus. Although members of the agile team may perform

different tasks and bring different skills to the project, all should be
focused on one goal—to deliver a working software increment to the
customer within the time promised.

• Collaboration. Software engineering (regardless of process) is about

assessing, analyzing, and using information that is communicated to
the software team; To accomplish these tasks, team members must
collaborate—with one another and all other stakeholders.
• Decision-making ability. Any good software team (including agile
teams) must be allowed the freedom to control its own destiny. This
implies that the team is given autonomy—decision-making authority
for both technical and project issues.

• Fuzzy problem-solving ability. Software managers must recognize

that the agile team will continually have to deal with ambiguity and
will continually be buffeted by change. In some cases, the team must
accept the fact that the problem they are solving today may not be the
problem that needs to be solved tomorrow. However, lessons learned
from any problem-solving
• Mutual trust and respect. The agile team must become what
DeMarco and Lister [DeM98] call a “jelled” team . A jelled team exhibits
the trust and respect that are necessary to make them “so strongly knit
that the whole is greater than the sum of the parts.”

• Self-organization. In the context of agile development, self-

organization implies three things:

(1) the agile team organizes itself for the work to be done,
(2) the team organizes the process to best accommodate its local environment,
(3) the team organizes the work schedule to best achieve delivery of the software
increment
 Extreme Programming (XP)
The most widely used approach to agile software development is
Extreme Programming, the seminal work on the subject has been written
by Kent Beck.

• XP values

• The XP Process

• Industrial XP

• The XP Debate
 XP values

Beck defines a set of five values that establish a foundation for all work
performed as part of XP, Each of these values is used as a driver for
specific XP activities, actions, and tasks.

1. communication,
2. Simplicity-Refactoring allows a software engineer to improve the
internal structure of a design (or source code) without changing its
external functionality or behavior. In essence, refactoring can be used to
improve the efficiency, readability, or performance of a design or the
code that implements a design
3. feedback,
4. courage, and
5. respect.
 The XP Process
• XP uses an object-oriented approach as its preferred development
paradigm,defines four (4) framework activities

1. Planning
2. Design
3. Coding
4. Testing
 simple design spike solutions
CRC cards prototypes
user stories
values
acceptance test criteria
iteration plan
n
desig

ing
plann g
codin
refactoring

pair programming
test
Release
unit test
software increment continuous integration
project velocity computed

acceptance testing
 Industrial XP

• Joshua Kerievsky [Ker05] describes Industrial Extreme Programming

(IXP) in the following manner: “IXP is an organic evolution of XP. It is
imbued with XP’s minimalist, customer-centric, test-driven spirit.

• IXP differs most from the original XP in its greater inclusion of

management, its expanded role for customers, and its upgraded
technical practices.”

• IXP incorporates six new practices that are designed to help ensure
that an XP project works successfully for significant projects within a
large organization
1. Readiness assessment

2. Project community.

3. Project chartering

4. Test-driven management

5. Retrospectives

6. Continuous learning
 The XP Debate
• Stephens and Rosenberg argue that many XP practices are worthwhile,
but others have been overhyped, and a few are problematic.

• The authors suggest that the co dependent nature of XP practices are

both its strength and its weakness.

• Because many organizations adopt only a subset of XP practices, they

weaken the efficacy of the entire process. Among the issues that
continue to trouble some critics of XP are

– Requirements volatility.
– Conflicting customer needs.
– Requirements are expressed informally
– Lack of formal design
 Scrum
• Scrum is an agile software development method that was conceived by
Jeff Sutherland and his development team in the early 1990s.

• In recent years, further development on the Scrum methods has been

performed by Schwaber and Beedle .

• Scrum principles are consistent with the agile manifesto and are used
to guide development activities within a process that incorporates the
following framework activities: requirements, analysis, design,
evolution, and delivery.
• Scrum incorporates a set of process patterns that emphasize project
priorities, compartmentalized work units, communication, and
frequent customer feedback.

• Backlog—a prioritized list of project requirements or features that provide

business value for the customer.

• Sprints—consist of work units that are required to achieve a requirement

defined in the backlog that must be fit into a predefined time-box.

• Demos—deliver the software increment to the customer so that

functionality that has been implemented can be demonstrated and
evaluated by the customer.
 Scrum meetings
• Scrum meetings—are short (typically 15 minutes) meetings held daily
by the Scrum team. Three key questions are asked and answered by all
team members :

• What did you do since the last team meeting?

• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?

• A team leader, called a Scrum master, leads the meeting and assesses
the responses from each person. The Scrum meeting helps the team to
uncover potential problems as early as possible. Also, these daily
meetings lead to “knowledge socialization” and thereby promote a self-
organizing team structure
 The Dynamic Systems Development Method

• The Dynamic Systems Development Method (DSDM) [Sta97] is an agile

software development approach that “provides a framework for
building and maintaining systems which meet tight time constraints
through the use of incremental prototyping in a controlled project
environment” .

• The consortium has defined an agile process model, called the DSDM life
cycle that defines three different iterative cycles, preceded by two
additional life cycle activities.
• Feasibility study —establishes the basic business requirements and constraint

• Business study —establishes the functional and information requirements

• Functional model iteration- produces a set of incremental prototypes that

demonstrate functionality for the customer

• Design and build iteration —revisits prototypes built during functional model
iteration to ensure that each has been engineered in a manner that will enable it to
provide operational business value for end users.

• Implementation—It should be noted that

– (1) the increment may not be 100 percent complete or
– (2) changes may be requested as the increment is put into place.
• In either case, DSDM development work continues by returning to the
functional model iteration activity.

• DSDM can be combined with XP to provide a combination approach that

defines a solid process model (the DSDM life cycle) with the nuts and bolts
practices (XP) that are required to build software increments.
 Agile Unified Process (AUP)
• The Agile Unified Process (AUP) adopts a “serial in the large” and
“iterative in the small” philosophy for building computer-based
systems. By adopting the classic UP phased activities—
– inception,
– elaboration,
– construction, and
– transition—AUP

• Each AUP iteration addresses the following activities

1. Modeling- UML representations of the business and problem
domains are created.

2. Implementation-Models are translated into source code.

3. Testing-Like XP, the team designs and executes a series of tests to

uncover errors and ensure that the source code meets its
requirements.

4. Deployment-focuses on the delivery of a software increment and the

acquisition of feedback from end users.
5. Configuration and project management-In the context of AUP,
configuration management addresses change management, risk
management ,and the control of any persistent work. Project
management tracks and controls the progress of the team and
coordinates team activities.

6. Environment management- Environment management co

ordinates a process infrastructure that includes standards, tools, and
other support technology available to the team.
Requirements Engineering:

• Establishing the ground work,

• Eliciting requirements,
• Developing use cases,
• Building the Analysis model,
• Negotiating Requirements,
• Requirement Monitoring,
• Validating Requirements.
 1.Requirements Engineering
• The broad spectrum of tasks and techniques that lead to an
understanding of requirements is called requirements engineering.

• From a software process perspective, requirements engineering is a

major software engineering action that begins during the
communication activity and continues into the modeling activity.

• Requirements engineering builds a bridge to design and

construction.

• Requirements engineering provides the appropriate mechanism for

understanding what the customer wants, analyzing need, assessing
feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the
requirements .
Tasks involved

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Requirements Management
 Inception (Beginning)
•Most projects begin when a business need is identified or a potential
new market or service is discovered.

•Stakeholders from the business community (e.g., business managers,

marketing people, product managers) define a business case for the
idea, try to identify the breadth and depth of the market, do a rough
feasibility analysis, and identify a working description of the project’s
scope.

•At project inception, a basic understanding of the problem, the people

who want a solution, the nature of the solution that is desired, and the
effectiveness of preliminary communication and collaboration
between the other stakeholders and the software team.
.
 Elicitation: (Extraction)
• Eliciting requirements is difficult because of

• Problems of scope-Identify the boundaries of the system.

• Problems of understanding -Domain , computing environment.
• Problems of Volatility -Requirements may change over time.

• Elicitation may be accomplished through two activities:

 Collaborative Requirements Gathering

 Quality Function Deployment.
 Elaboration (explanation)
•The information obtained from the customer during inception
and elicitation is expanded and refined during elaboration.

•This task focuses on developing a refined requirements model

that identifies various aspects of software function, behavior, and
information.

•Elaboration is a good thing, but you have to know when to stop.

The key is to describe the problem in a way that establishes a firm
base for design. If you work beyond that point, you’re doing design
 Negotiation (Cooperation)

•Customers, users, and other stakeholders are asked to rank

requirements and then discuss conflicts in priority.

•Using an iterative approach that prioritizes requirements, assesses

their cost and risk, and addresses internal conflicts, requirements
are eliminated, combined, and/or modified so that each party
achieves some measure of satisfaction.

•There should be no winner and no loser in an effective negotiation.

Both sides win, because a “deal” that both can live with is solidified
 Specifications
1. 1. A specification can be a written document, a set of graphical
models, a formal mathematical model, a collection of usage
scenarios, a prototype, or any combination of these.

2. 2. For large systems, a written document, combining natural

language descriptions and graphical models may be the best
approach.

3. 3. However, usage scenarios may be all that are required for smaller
products.
 Validation
1. 1. The work products produced as a consequence of
requirements engineering are assessed for quality during a
validation step.

2. 2. Requirements validation examines the specification to ensure

that all software requirements have been stated unambiguously;
that inconsistencies, omissions, and errors have been detected and
corrected; and that the work products conform to the standards
established for the process, the project, and the product.
 Requirements management
1. 1. Requirements management is a set of activities that help the
project team identify, control, and track requirements and changes
to requirements at any time as the project proceeds.

2. 2. Many of these activities are identical to the software

configuration management (SCM).
2.Ground Work Establishment
Ground Work for Requirement Analysis consist of

1.Identifying stakeholders-“anyone who benefits in a direct or

indirect way from the system which is being developed.”

• Project Manager
• Team Members
• Team Leads
• Project Resource Manager
• Senior Managers
• Executives or Sponsors
2. Recognizing viewpoints-“Put three stakeholders in a room and ask
them what kind of system they want. You’re likely to get four or more
different opinions.

•Marketing group is interested in functions and features that will

excite the potential market, making the new system easy to sell.

• Business managers are interested in a feature set that can be built

within budget and that will be ready to meet defined market windows.

•End users may want features that are familiar to them and that are
easy to learn and use.

•Software engineers may be concerned with functions that are

invisible to nontechnical stakeholders but that enable an
infrastructure that supports more marketable function
3.Working towards collaboration-The job of a requirements
engineer is to identify areas of commonality (i.e., requirements on
which all stakeholders agree) and areas of conflict or
inconsistency (i.e., requirements that are desired by one
stakeholder but conflict with the needs of another stakeholder

•A strong “project champion”(e.g., a business manager or a senior

technologist) may make the final decision about which
requirements make the cut.
4.Asking the First Questions

•Who is behind the request for this work?

• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
• How would you characterize “good” output that would be
generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which
the solution will be used?
• Will special performance issues or constraints affect the way the
solution is approached
 3. Eliciting requirements
•Requirements elicitation (also called requirements gathering)
combines elements of problem solving, elaboration, negotiation, and
specification.

1.Collaborative Requirements Gathering

•Meetings are conducted and attended by both software engineers

and other stakeholders.

• Rules for preparation and participation are established.

• An agenda is suggested that is formal enough to cover all

important points but informal enough to encourage the free flow of
ideas.
• A “facilitator” (can be a customer, a developer, or an outsider)
controls the meeting.

. • A “definition mechanism” (can be work sheets, flip charts, or wall

stickers or an electronic bulletin board, chat room, or virtual forum)
is used
2. Quality Function Deployment-Quality function deployment
(QFD) is a quality management technique that translates the needs
of the customer into technical requirements for software.QFD
identifies three types of requirements.

1. Normal requirements

2. Expected requirements

3. Exciting requirements
3 .Usage Scenarios -developers and users can create a set of
scenarios that identify a thread of usage for the system to be
constructed.

The scenarios, often called use cases, provide a description of how

the system will be used.
4. Elicitation Work Products –a consequence of requirements
elicitation

• A statement of need and feasibility.

• A bounded statement of scope for the system or product.

• A list of stakeholders who participated in requirements

elicitation.

• A description of the system’s technical environment.

• A list of requirements and the domain constraints.

• A set of usage scenarios that provide insight.

• Any prototypes developed to better define requirements

 3. Building Use Cases
•Use cases are defined from an actor’s point of view. An actor is a
role that people (users) or devices play as they interact with the
software.

•It is important to note that an actor and an end user are not
necessarily the same thing. A typical user may play a number of
different roles when using a system,

• whereas an actor represents a class of external entities (often, but

not always, people) that play just one role in the context of the use
case.
Once actors have been identified, use cases can be developed. Jacobson
suggests a number of questions should be answered by a use case:

• Who is the primary actor, the secondary actor(s)?

• What are the actor’s goals?

• What preconditions should exist before the story begins?

• What main tasks or functions are performed by the actor?

• What exceptions might be considered as the story is described?

• What variations in the actor’s interaction are possible?

• What system information will the actor acquire, produce, or change?

• Will the actor have to inform the system about changes in the
external environment?

• What information does the actor desire from the system?

• Does the actor wish to be informed about unexpected changes

Sample Use case Diagram
 4.Building the Analysis model
The intent of the analysis model is to provide a description of the
required informational, functional, and behavioral domains for a
computer-based system.

1.Elements of the Requirements Model

Different modes of representation force you to consider

requirements from different viewpoints—an approach that has a
higher probability of uncovering omissions, inconsistencies, and
ambiguity
•Scenario-based elements
Class-based elements

•The system is described from the user’s point of view using a

scenario-based approach

•Scenario-based elements of the requirements model are often

the first part of the model that is developed.

•Each usage scenario implies a set of objects that are

manipulated as an actor interacts with the system. These
objects are categorized into classes—a collection of things that
have similar attributes and common behaviors.
•It is always a good idea to get stakeholders involved.

•One of the best ways to do this is to have each stakeholder

write use cases that describe how the software will be used
•Behavioral elements

•The behavior of a computer-based system can have a profound

effect on the design that is chosen and the implementation
approach that is applied.

•The state diagram is one method for representing the behavior of a

system by depicting its states and the events that cause the system to
change state.

• A state is any externally observable mode of behavior. In addition,

the state diagram indicates actions (e.g., process activation) taken as a
consequence of a particular event.
Flow-oriented elements

•Information is transformed as it flows through a computer-based

system. The system accepts input in a variety of forms, applies
functions to transform it, and produces output in a variety of forms.

• Input may be a control signal transmitted by a transducer, a series

of numbers typed by a human operator, packet of information
transmitted on a network link, or a voluminous data file retrieved
from secondary storage.

•The transform(s) may comprise a single logical comparison, a

complex numerical algorithm, or a rule-inference approach of an
expert system. Output may light a single LED or produce a 200-
page report
2.Analysis Patterns

•First, analysis patterns speed up the development of abstract analysis

models that capture the main requirements of the concrete problem
by providing reusable analysis models with examples as well as a
description of advantages and limitations.

• Second, analysis patterns facilitate the transformation of the analysis

model into a design model by suggesting design patterns and reliable
solutions for common problems.

•suggest solutions (e.g., a class, a function, a behavior) within the

application domain that can be reused when modeling many
applications
 5.Negotiating Requirements
•A compromise is the art of dividing a cake in such a way that
everyone believes he has the biggest piece.

•The intent of this negotiation is to develop a project plan that meets

stakeholder needs while at the same time reflecting the real-world
constraints (e.g., time, people, budget) that have been placed on the
software team.
 The Art of Negotiation
Learning how to negotiate effectively can serve you well throughout
your personal and technical life.

1.Recognize that it’s not a competition. To be successful, both

parties have to feel they’ve won or achieved something. Both
will have to compromise.

2. Map out a strategy. Decide what you’d like to achieve; what the
other party wants to achieve, and how you’ll go about making
both happen.

3. Listen actively. Don’t work on formulating your response while

the other party is talking. Listen to her. It’s likely you’ll gain
knowledge that will help you to better negotiate your position.
4. Focus on the other party’s interests. Don’t take hard positions if
you want to avoid conflict.

5. Don’t let it get personal. Focus on the problem that needs to be

solved.

6. Be creative. Don’t be afraid to think out of the box if you’re at an

impasse.

7. Be ready to commit. Once an agreement has been reached, don’t

waffle; commit to it and move on.
 6.Validating Requirements
As each element of the requirements model is created, it is
examined for inconsistency, omissions, and ambiguity.

• Is each requirement consistent with the overall objectives for the

system/product?

• Have all requirements been specified at the proper level of

abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?

• Is the requirement really necessary or does it represent an add-

on feature that may not be essential to the objective of the
system?

• Is each requirement bounded and unambiguous?

 • Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?

• Do any requirements conflict with other requirements?

• Is each requirement achievable in the technical environment that

will house the system or product?

• Is each requirement testable, once implemented?

• Does the requirements model properly reflect the information,

function, and behavior of the system to be built?
DESIGN CONCEPTS

•The design process

•Design Concepts
•The design model
 Introduction
Mitch Kapor, the creator of Lotus 1-2-3, presented a “software design
manifesto” in Dr. Dobbs Journal. He said: Good software design should
exhibit:

 Firmness: A program should not have any bugs that inhibit its
function.
 Commodity: A program should be suitable for the purposes for which
it
was intended.

 Delight: The experience of using the program should be pleasurable

one
 DESIGN WITH THE CONTEXT OF SE
• “The most common miracle of software engineering is the transition
from analysis to design and design to code.”

• Software design sits at the technical kernel of software engineering

and is applied regardless of the software process model that is used.

• Beginning once software requirements have been analyzed and

modeled, software design is the last software engineering action
within the modeling activity and sets the stage for construction(code
generation and testing).
Translating the requirements model into the design model
• The data/class design transforms class models into design class
realizations and the requisite data structures required to implement
the software.

• The architectural design defines the relationship between major

structural elements of the software, the architectural styles and design
patterns that can be used to achieve the requirements defined for the
system, and the constraints that affect the way in which architecture
can be implemented.
• The interface design describes how the software communicates with
systems that interoperate with it, and with humans who use it. An
interface implies a flow of information (e.g., data and/or control) and a
specific type of behavior.

• The component-level design transforms structural elements of the

software architecture into a procedural description of software
components.
 DESIGN PROCESS
•Software design is an iterative process through which
requirements are translated into a “blueprint” for constructing the
software.

•The blueprint depicts a holistic view of software.

1.Software Quality Guidelines and Attributes
• The design must implement all of the explicit
requirements contained in the requirements model, and it must
accommodate all of the implicit requirements desired by
stakeholders.

• The design must be a readable, understandable guide for

those who generate code and for those who test and
subsequently support the software.

• The design should provide a complete picture of the

software, addressing the data, functional, and behavioral
domains from an implementation perspective.
 Software Quality Guidelines
 A design should exhibit an architecture that

(1)has been created using recognizable architectural styles or

patterns,
(2)is composed of components that exhibit good design
characteristics and
(3) can be implemented in an evolutionary fashion

For smaller systems, design can sometimes be developed linearly.

 A design should be modular; that is, the software should be logically

partitioned into elements or subsystems

 A design should contain distinct representations 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 characteristics.

 A design should lead to interfaces 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.

 A design should be represented using a notation that effectively

communicates its meaning.
 Software Quality Attributes
• Functionality- assessed by evaluating the feature set and capabilities of
the program.

• Usability- assessed by considering human factors overall aesthetics,

consistency, and documentation.

• Reliability- evaluated by measuring the frequency and severity of failure.

• Performance- measured by considering processing speed, response time,

resource consumption, throughput, and efficiency.

• Supportablity- combines the ability to extend the program (extensibility),

adaptability, serviceability
2.The Evolution of Software Design
• Procedural aspects of design definition evolved into a philosophy called
structured programming .

• Newer design approaches proposed an object-oriented approach to

design derivation.

• Growing emphasis on aspect-oriented methods model-driven

development and test-driven development emphasize techniques for
achieving more effective modularity and architectural structure in the
designs that are created.
• All of these methods have a number of common characteristics:

(1) a mechanism for the translation of the requirements model into a

design representation,

(2) a notation for representing functional components and their

interfaces,

(3) heuristics for refinement and partitioning, and

(4) guidelines for quality assessment

 2.Design Concepts
• A set of fundamental software design concepts has evolved over the
history of software engineering.

• Each provides the software designer with a foundation from which

more sophisticated design methods can be applied. Each helps you
answer the following questions:

– What criteria can be used to partition software into individual

components?
– How is function or data structure detail separated from a
conceptual representation of the software?
– What uniform criteria define the technical quality of a software
design?
• M. A. Jackson [Jac75] 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—data, procedure, control

 Architecture—the overall structure of the software

 Patterns—”conveys the essence” of a proven design solution

 Separation of concerns—any complex problem can be more easily

handled if it is subdivided into pieces

 Modularity—compartmentalization of data and function

 Hiding—controlled interfaces

7
 Functional independence—single-minded function and low coupling

 Refinement—elaboration of detail for all abstractions

 Aspects—a mechanism for understanding how global requirements
affect design
 Refactoring—a reorganization technique that simplifies the design

 OO design concepts—OO design concepts such as classes and

objects, inheritance, messages, and polymor phism, among others.
 Design Classes—provide design detail that will enable analysis
classes to be implemented

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

8
A procedural abstraction refers to a sequence of instructions that
have a specific and limited function.

details of
enter
algorithm

implemented with a "knowledge" of

the object that is associated with enter

9
 2.Architecture
“The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.”

Structural properties. This aspect of the architectural design

representation defines the components of a system (e.g., modules,
objects, filters) and the manner in which those components are
packaged and interact with one another.

Extra-functional properties. The architectural design description

should address how the design architecture achieves requirements for
performance, capacity, reliability, security, adaptability, and other
system characteristics.

Families of related systems. The architectural design should draw

upon repeatable patterns that are commonly encountered in the design
of families of similar systems. In essence, the design should have the
ability to reuse architectural building blocks.
10
 3.Patterns
Design Pattern Template

• Pattern name—describes the essence of the pattern in a short but

expressive name
• Intent—describes the pattern and what it does
• Also-known-as—lists any synonyms for the pattern
• Motivation—provides an example of the problem
• Applicability—notes specific design situations in which the pattern is
applicable
• Structure—describes the classes that are required to implement the pattern
• Participants—describes the responsibilities of the classes that are
• required to implement the pattern
• Collaborations—describes how the participants collaborate to carry out their
responsibilities
• Consequences—describes the “design forces” that affect the pattern and the
potential trade-offs that must be considered when the pattern is implemented
• Related patterns—cross-references related design patterns
11
• Design pattern describes a design structure that solves a particular
design problem within a specific context and amid “forces” that may
have an impact on the manner in which the pattern is applied and used.

• The intent of each design pattern is to provide a description that

enables a designer to determine
(1) whether the pattern is applicable to the current work,
(2) whether the pattern can be reused (hence, saving design time), and
(3) whether the pattern can serve as a guide for developing a similar, but
functionally or structurally different pattern
 4.Separation of Concerns

 Any complex problem can be more easily handled if it is

subdivided into pieces that can each be solved and/or optimized
independently

 A concern is a feature or behavior that is specified as part of the

requirements model for the software

 By separating concerns into smaller, and therefore more

manageable pieces, a problem takes less effort and time to solve.

1
 5.Modularity

 "modularity is the single attribute of software that allows a program

to be intellectually manageable" .
 Monolithic software (i.e., a large program composed of a single
module) 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.
 In almost all instances, you should break the design into many
modules, hoping to make understanding easier and as a consequence,
reduce the cost required to build the software.

13
Cost
of
Total software cost

effort Cost to integrate

Region of minimum cost

M

Number of modules
 6.Information Hiding

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

•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
 7.Functional Independence
 Functional independence is achieved by developing modules with
"single-minded" function and an "aversion" to excessive
interaction with other modules.

 Cohesion is an indication of the relative functional strength

of a module.A cohesive module performs a single task,
requiring little interaction with other components in other
parts of a program. Stated simply, a cohesive module should
(ideally) do just one thing.

 Coupling is an indication of the relative interdependence among

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

19
 8.Refinement
• Refinement is actually a process of elaboration.

• Abstraction and refinement are complementary concepts. Abstraction

enables you to specify procedure and data internally but suppress the
need for “outsiders” to have knowledge of low-level details.

• Refinement helps you to reveal low-level details as design progresses.

Stepwise Refinement
open

walk to door;
reach for
knob;
open door; repeat until door opens

walk if knob doesn't turn,

through; then
find correct
key; insert in
lock;
endif
pull/push door
move out of
way; end repeat

17
 9.Aspects
 Consider two requirements, A and B. Requirement A crosscuts
requirement B “if a software decomposition [refinement] has
been chosen in which B cannot be satisfied without taking A
into account.

 An aspect is a representation of a cross-cutting concern.

 Cross-cutting concerns are parts of a program that rely on or must

affect many other parts of the system. They form the basis for the
development of aspects. Such cross-cutting concerns do not fit cleanly
into object-oriented programming or procedural programming.

20
 10.Refactoring
 Fowler [FOW99] defines refactoring in the following manner:
 "Refactoring is the process of changing a software system in such
a way that it does not alter the external behavior of the code
[design] yet improves its internal structure.”

 When software is refactored, the existing design is examined for

 Redundancy
 unused design elements
 inefficient or unnecessary algorithms
 poorly constructed or inappropriate data structures
 or any other design failure that can be corrected to yield a better
design.

22
 11.OO Design Concepts

 Inheritance—all responsibilities of a superclass is

immediately inherited by all subclasses

 Messages—stimulate some behavior to occur in the receiving

object

 Polymorphism—a characteristic that greatly reduces the effort

required to extend the design

23
 12.Design Classes
Five different types of design classes, each representing a different layer
of the design architecture.

• User interface classes define all abstractions that are necessary for
humancomputer interaction (HCI).

• Business domain classes are often refinements of the analysis

• Process classes implement lower-level business abstractions

• Persistent classes represent data stores (e.g., a database) that will

persist beyond the execution of the software.

• System classes implement software management and control functions

that enable the system to operate and communicate within its
computing environment and with the outside
24
 3.Design Model
• The process dimension indicates the evolution of the design
model as design tasks are executed as part of the software
process.

• The abstraction dimension represents the level of detail as each

element of the analysis model is transformed into a design
equivalent and then refined iteratively.

26
 1.Data Design Element
• 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 (the
customer/user’s view of data).

• This data model is then refined into progressively more implementation-specific

representations that can be processed by the computer-based system.

• 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.
 2.Architectural Elements
 The Architectural design elements give us an overall view of the
software,architectural model is derived from three sources:

 information about the application domain for the

software to be built;

 specific requirements 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 and styles

27
3.Interface Design Elements
• The interface design elements for software depict information flows
into and out of the system and how it is communicated among the
components defined as part of the architecture. There are three
important elements of interface design:

• (1) the user interface (UI);

• (2) external interfaces to other systems, devices, networks, or other

producers or consumers of information; and

• (3) internal interfaces between various design components.

4.Component-Level Design Elements
• The component-level design for software fully describes the internal
detail of each software component.

• To accomplish this, the component-level design defines data structures

for all local data objects and algorithmic detail for all processing that
occurs within a component and an interface that allows access to all
component operations (behaviors)
5.Deployment-Level Design Element
• Deployment-level design elements indicate how software functionality
and subsystems will be allocated within the physical computing
environment that will support the software.
Thank you
.