Software Engineering

Software Engineering

214454

Second Year IT Semester-II (2019 Pattern)

Dr. S V Gumaste.

1

What is Software?

•

Software is:

(1) instructions (computer programs) that when executed provide

desired features, function, and performance;

(2) data structures that enable the programs to adequately manipulate

information and

(3) documentation that describes the operation and use of the

programs.

2

What is Software?

•

Software is developed or engineered, it is not manufactured in the

classical sense.

•

 Software doesn't "wear out."

•

 Although the industry is moving toward component-based

construction, most software continues to be custom-built.

3

Failure curves for Hardware:

4

Failure curves for Software:

                          (Wear vs. Deterioration)

5

Software and Hardware Curve:

Software is not

susceptible to the

environmental

maladies that cause

hardware to wear

out.

6

Software Applications

System software: 

OS, Compiler, Editor, Linker, Loader, Assembler

Application software: 

Pay role, Library Management, Hospital Management

Engineering/scientific software : 

Applications range from astronomy to

volcanology, from automotive stress analysis to space shuttle orbital

dynamics, and from molecular biology to automated manufacturing.

Embedded software:

 Resides within a product or system and is used to

implement and control features and functions for the end user and for the

system itself.  S/W for Washing Machine, ATM

7

S/W Applications:

Product-line software: 

Designed to provide a specific capability for use by

many different customers. Product-line software can focus on a limited and

esoteric marketplace (e.g., inventory control products) or address mass

consumer markets (e.g., word processing, spreadsheets, computer graphics,

multimedia, entertainment

WebApps (Web applications): 

WebApps are evolving into sophisticated

computing environments that not only provide stand-alone features,

computing functions, and content to the end user, but also are integrated

with corporate databases and business applications.

AI software: 

Makes use of non-numerical algorithms to solve complex

problems. Eg: robotics, expert systems, pattern recognition, AI, gaming

8

Software—New Categories

•

Open world computing—

The

rapid growth of wireless networking may soon lead

to true pervasive, distributed computing

•

Ubiquitous computing—

Ubiquitous computing would be everywhere,

and pervasive computing would be in all parts of your life.

•

Netsourcing

—The World Wide Web is rapidly becoming a computing engine as

well as a content provider. The challenge for software engineers is to architect

simple and sophisticated applications that provide a benefit to targeted end-user

markets worldwide.

•

Open source

— Growing trend that results in distribution of source code for

systems applications (e.g., operating systems, database, and development

environments) so that many people can contribute to its development. The

challenge for software engineers is to build source code 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

9

Legacy Software: Why must it change?

•

Software must be adapted to meet the needs of new computing

environments or technology.

•

Software must be enhanced to implement new business requirements.

•

Software must be extended to make it’s ability to work with other

more modern systems or databases.

•

Software must be re-architected to make it viable within a network

environment.

10

Software Engineering:

•

Some realities: A concerted effort should be made to understand the problem

before a software solution is developed design becomes a pivotal activity

software should exhibit high quality, software should be maintainable.

•

The seminal definition: [Software engineering is] the establishment and use of

sound engineering principles in order to obtain economically software that is

reliable and works efficiently on real machines.

•

The IEEE definition: Software Engineering: (1) The application of a systematic,

disciplined, quantifiable approach to the development, operation, and

maintenance of software; that is, the application of engineering to software.

(2) The study of approaches as in (1).

11

A Layered Technology:

12

•

Process defines a framework that must be established for effective

delivery of software engineering technology. The software process

forms the basis for management control of software projects and

establishes the context in which technical methods are applied, work

products (models, documents, data, reports, forms, etc.) are

produced, milestones are established, quality is ensured, and change

is properly managed.

•

Methods encompass a broad array of tasks that include

communication, requirements analysis, design modeling, program

construction, testing, and support.

•

Tools provide automated or semi-automated support for the process

and the methods.

13

Umbrella Activities:

Software project tracking and control

—allows the software team to assess progress

against the project plan and take any necessary action to maintain the schedule.

Risk management—

assesses risks that may affect the outcome of the project or the

quality of the product.

Software quality assurance—

defines

and conducts the activities required to ensure

software quality.

Technical reviews—

assesses

software engineering work products in an effort to uncover

and remove errors before they are propagated to the next activity.

Measurement

—defines and collects process, project, and product measures that assist the

team in delivering software that meets stakeholders’ needs; can be used in conjunction

with all other framework and umbrella activities.

Software configuration management—

manages

the effects of change throughout the

software process.

Reusability management—

defines criteria for work product reuse (including software

components) and establishes mechanisms to achieve reusable components.

Work product preparation and production—

encompasses

the activities required to create

work products such as models, documents, logs, forms, and lists.

14

•

A process is a collection of activities, actions, and tasks that are

performed when some work product is to be created.

•

An 

activity 

strives to achieve a broad objective (e.g., communication

with stakeholders) and is applied regardless of the application

domain, size of the project, complexity of the effort, or degree of

rigor with which software engineering is to be applied.

•

An 

action

 (e.g., architectural design) encompasses a set of tasks that

produce a major work product (e.g., an architectural design model).

•

A 

task

 focuses on a small, but well-defined objective (e.g., conducting

a unit test) that produces a tangible outcome.

15

Software Myth:

•

Misleading attitudes that have caused serious problems.

•

Management myths:

 Managers with software responsibility are often

under pressure to maintain budgets, keep schedules from slipping,

and improve quality.

•

Customer myths:

 Customer myths lead to false expectations (by the

customer) and ultimately, dissatisfaction with the developer.

•

Practitioner’s myths

: Overconfidence (like It will work!)

16

M

a

n

a

g

e

m

e

n

t

m

y

t

h

s

:

Myth

: We already have a book that’s full of

standards and procedures for building software,

won’t that provide my people with everything

they need to know?

Reality:

 The book of standards may very well

exist, but isn’t used. Most software practitioners

aren’t aware of its existence. Also, it doesn’t

reflect modern software engineering practices.

17

Myth: 

My people have state-of-the-art software

development tools, after all, we buy them the newest

computers.

Reality:

 It takes much more than the latest model

mainframe, workstation, or PC to do high-quality

software development. Computer-aided software

engineering (CASE) tools are more important than

hardware for achieving good quality and productivity,

yet the majority of software developers still do not use

them effectively.

M

a

n

a

g

e

m

e

n

t

m

y

t

h

s

C

o

n

t

i

n

u

e

d

…

.

18

Management Myth Cont’d

Myth: 

If we get behind schedule, we can add more

programmers and catch up (sometimes called the Mongolian

horde concept).

Reality: 

Software development is not a mechanistic process

like manufacturing. As new people are added, people who

were working must spend time educating the newcomers,

thereby reducing the amount of time spent on productive

development effort. People can be added but only in a

planned and well-coordinated manner.

19

Management Myth Cont’d

Myth: 

If I decide to outsource the software project to a

third party, I can just relax and let that firm build it.

Reality: 

If an organization does not understand how to

manage and control software projects internally, it will

invariably struggle when it outsources software

projects.

20

C

u

s

t

o

m

e

r

m

y

t

h

s

:

Myth

: A general statement of objectives is sufficient to

begin writing programs-we can fill in the details later.

Reality:

 A poor up-front definition is the major cause of

failed software efforts. A formal and detailed description

of the functions, behavior, performance, interfaces, design

constraints, and validation criteria is essential.

21

C

u

s

t

o

m

e

r

m

y

t

h

s

:

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. When changes are requested during software

design, the cost impact grows rapidly. Resources have been

committed and a design framework has been established.

Change can cause heavy additional costs. Change, when

requested after software is in production, can be much more

expensive than the same change requested earlier.

22

P

r

a

c

t

i

t

i

o

n

e

r

’

s

m

y

t

h

s

:

Myth

: Once we write the program and get it to work, our job is done.

Reality

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

23

P

r

a

c

t

i

t

i

o

n

e

r

’

s

m

y

t

h

s

c

o

n

t

’

d

:

Myth

: Until I get the program “running” I have no way of assessing its

quality.

Reality

: One of the most effective software quality assurance

mechanisms can be applied from the inception of a project—the formal

technical review.

24

P

r

a

c

t

i

t

i

o

n

e

r

’

s

m

y

t

h

s

c

o

n

t

’

d

:

•

Myth

: The only deliverable work product for a successful project is

the working program.

•

Reality: 

A working program is only one part of a software

configuration that includes many elements. A variety of work

products (e.g., models, documents, plans) provide a foundation for

successful engineering and, more important, guidance for software

support

25

G

e

n

e

r

i

c

P

r

o

c

e

s

s

M

o

d

e

l

/

F

r

a

m

e

w

o

r

k

A

c

t

i

v

i

t

i

e

s

:

Communication:

Planning:

Modeling:

Analysis of requirements:

Design:

Construction

:

Code generation:

Testing:

Deployment:

26

Process flow:

•

process flow

—describes how the

frame work activities and the

actions and tasks that occur

within each framework activity

are organized with respect to

sequence and time

27

Linear process:

•

A 

linear process flow 

executes each of the five framework activities in

sequence, beginning with communication and culminating with

deployment

28

Iterative process

•

An 

iterative process flow 

repeats one or more of the activities before

proceeding to the next

29

Incremental model

•

The 

incremental 

model combines elements of linear and parallel

process flows.

30

Incremental Model cont’d

•

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;

•

Advanced page layout capability in the fourth increment.

•

It should be noted that the process flow for any increment can

incorporate the prototyping paradigm.

31

A

g

i

l

e

s

o

f

t

w

a

r

e

d

e

v

e

l

o

p

m

e

n

t

•

What is it

? - Combines a philosophy & a set of development guidelines

•

Who does it

? - Project stakeholders

•

Why is it important

? - A reasonable alternative to conventional quick look

software engineering for certain classes of software and certain types of

software projects. It has been demonstrated to deliver successful systems

quickly.

•

What are the steps

? - The basic framework activities—communication,

planning, modeling, construction, and deployment— remain. But they

morph into a minimal task set that pushes the project team toward

construction and delivery.

•

What is the work product

? - Both the customer and the software engineer

have the same view—the only really important work product is an

operational “software increment” that is delivered to the customer on the

appropriate commitment date.

•

How do I ensure that I’ve done it right

?-Agile team agrees that the process

works, and the team produces deliverable software increments that satisfy

the customer.

32

“Manifesto for Agile Software Development.”

•

It stated that: We are uncovering better ways of developing software

by doing it and helping others do it. Through this work we have come

to value:

•

Individuals and interactions 

over processes and tools

•

Working software 

over comprehensive documentation

•

Customer collaboration 

over contract negotiation

•

Responding to change 

over following a plan

•

That is, while there is value in the items on the right, we value the

items on the left more.

33

What is agility?

•

Ivar Jacobson provides a useful discussion:

•

Agility 

has become today’s buzzword when describing a modern software

process. Every one is agile. An agile team is a nimble team / able to pivot in

a new direction as the environment demands, able to appropriately

respond to changes.

•

Change is what software development is very much about.

•

Changes in the software being built,

•

changes to the team members,

•

changes because of new technology,

•

changes of all kinds that may have an impact on the product they build or the

project that creates the product.

•

Support for changes should be built-in everything we do in software,

something we embrace because it is the heart and soul of software.

•

An agile team recognizes that software is developed by individuals working

in teams and that the skills of these people, their ability to collaborate is at

the core for the success of the project.

34

Agility and cost of change:

35

Agile Process:

•

Any agile software process is characterized in a manner that

addresses a number of key assumptions about the majority of

software projects:

•

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.

36

Agility Principles:  

[12 Principles]

•

Our highest priority is to satisfy the customer through early and continuous

delivery of valuable software.

•

Welcome changing requirements, even late in development. Agile

processes harness change for the customer’s competitive advantage.

•

Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

•

Business people and developers must work together daily throughout the

project.

•

Build projects around motivated individuals. Give them the environment

and support they need, and trust them to get the job done.

•

The most efficient and effective method of conveying information to and

within a development team is face-to-face conversation.

37

Agility Principles cont’d

•

Working software is the primary measure of progress.

•

Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace

indefinitely.

•

Continuous attention to technical excellence and good design

enhances agility.

•

Simplicity—the art of maximizing the amount of work not done—is

essential.

•

The best architectures, requirements, and designs emerge from self–

organizing teams.

•

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

effective, then tunes and adjusts its behavior accordingly.

38

Some facts/terms:

•

Agile development focuses on the talents and skills of individuals, molding the process to

specific people and teams.

•

Competence: 

talent, specific software-related skills, and overall knowledge of the

process that the team has chosen to apply.

•

Common focus: 

to deliver a working software increment to the customer within the time

promised.

•

Collaboration, Mutual trust and respect.

•

Decision-making ability: 

Team is given autonomy—decision-making authority for both

technical and project issues.

•

Fuzzy problem-solving ability: 

agile team will continually have to deal with ambiguity

and will continually be buffeted by change.

•

Self-organization. 

In the context of agile development, self-organization implies three

things:

(1) Agile team organizes itself for the work to be done,

(2) Team organizes the process to best accommodate its local environment,

(3) Team organizes work schedule to best achieve delivery of software increment.

39

1. Extreme Programming:

•

In order to illustrate an agile process in a bit more detail, we will study

an overview of 

Extreme Programming 

(XP), the most widely used

approach to agile software development. [Kent Beck, 1980]

•

Beck defines a set of 

five 

values

that establish a foundation for all

work performed as part of XP:

•

Communication

 - between stakeholders- informal, avoid voluminous

documentations

•

Simplicity

 - XP restricts developers to design only for immediate needs, rather

than consider future needs.

•

Feedback

 - is derived from three sources: the implemented software itself,

the customer, and other software team members.

•

Courage

 - strict adherence to certain 

Extreme Programming

 (XP) practices

demands 

courage. 

A better word might be 

discipline

•

Respect

 - Agile team inculcates 

respect 

among it members, between other

stakeholders and team members, and indirectly, for the software itself.

40

•

Extreme Programming 

uses an object-oriented approach as its preferred

development paradigm and encompasses a set of rules and practices that

occur within the context of four framework activities: planning, design,

coding, and testing.

•

Planning: 

The planning activity (also called 

the planning game

) begins with

listening

—a requirements gathering activity that enables the technical

members of the XP team to understand the business context for the software

and to get a broad feel for required output and major features and

functionality.

•

Design: 

XP design rigorously follows the KIS (keep it simple) principle. A simple

design is always preferred over a more complex representation.

•

Coding: 

After stories are developed and preliminary design work is done, the

team does 

not 

move to code, but rather develops a series of unit tests that

will exercise  each of the stories that is to be included in the current release

(software increment). Once the unit test has been created, the developer is

better able to focus on what must be implemented to pass the test.

•

Testing: 

Fixing small problems every few hours takes less time than fixing huge

problems just before the deadline.

41

Extreme Programming 

(XP) Process: Cont'd…

Class-Responsibility Collaborator

42

Other Agile Process Models:

•

Adaptive Software Development (ASD)

•

 Scrum

•

 Dynamic Systems Development

Method (DSDM)

•

Crystal

•

 Feature Drive Development (FDD)

•

 Lean Software Development (LSD)

•

 Agile Modeling (AM)

•

 Agile Unified Process (AUP)

All agile process models conform to the

Manifesto for Agile Software

Development and the Agile principles.

43

2. Adaptive Software Development (ASD) life cycle:

•

Adaptive Software Development 

(ASD) has been proposed by Jim

Highsmith as a technique for building complex software and systems.

The philosophical underpinnings of ASD focus on human collaboration

and team self-organization.

•

Highsmith argues that an agile, adaptive development approach based

on collaboration is “as much a source of 

order 

in our complex

interactions as 

discipline and engineering

” and incorporates three

phases, 

speculation

, collaboration, and learning.

44

Adaptive Software Development (ASD)

अनुमान

सहयोग

शिकत आहे

People working together

must trust one another to

(1) criticize without

animosity,

(2) assist without

resentment,

(3) work as hard as or

harder than they do,

(4) have the skill set

to contribute to the work at

hand,

(5) communicate problems

or concerns in a way that

leads to effective action.

45

3. SCRUM: 

(Jeff Sutherland and his development team in the early 1990)3

•

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.

•

work tasks occur within a process pattern called a 

sprint.

•

Backlog

—A prioritized list of project 

requirements/features

 that

provide business value for the customer. Items can be added to the

backlog at any time The product manager assesses the backlog &

updates as required.

•

Sprints

—Consist of work units that are required to achieve a

requirement defined in the backlog that must be fit into a predefined.

•

Scrum meetings

—Short meetings held daily by the Scrum team.

46

SCRUM Process:

Scrum Master

47

4. Dynamic Systems Development Method 

(DSDM)

•

DSDM is an iterative software process in which each iteration follows

the 80 percent rule. 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”.

•

Stages are:

•

Feasibility study

—Establishes the basic business 

requirements

 and

constraints

 associated with the application to be built and then

assesses whether the application is a viable candidate for the DSDM

process.

•

Business study

—Establishes the functional and information

requirements that will allow the application to provide business value;

also, defines the basic application architecture and identifies the

maintainability requirements for the application.

48

DSDM Cont'd……

•

Functional model iteration—

Produces a set of incremental prototypes

that demonstrate functionality for the customer. The intent during

this iterative cycle is to gather additional requirements by eliciting

feedback from users as they exercise the prototype.

•

Design and build iteration—

Revisits prototypes built during 

functional

model iteration 

to ensure that each has been engineered in a manner

that will enable it to provide operational business value for end users.

In some cases, 

functional model iteration 

and 

design and build

iteration 

occur concurrently.

•

Implementation—

Places the latest software increment into the

operational environment. It should be noted that

•

(1) the increment may not be 100 percent complete or

•

(2) changes may be requested as the increment is put into place.

49

5. Crystal:

•

Alistair Cockburn, credited as one of the original popularizers of agile,

developed the Crystal method for IBM in 1991. He decided to focus

not on developing specific step-by-step development strategies that

would work across the board for teams involved in any project, but

instead to develop guidelines for team collaboration and

communication. The traits of Cockburn’s Crystal method were

therefore all based around the team itself:

•

Human-powered (meaning the project should be flexible and tailored

to the needs and the preferred work modalities of people involved)

•

Adaptive (meaning the approach uses no fixed tools but can be altered

to meet the team’s specific needs)

•

Ultra-light (meaning this methodology does not require much

documentation or reporting)

50

•

Crystal’s strengths include:

•

Allows teams to work the way they deem most

effective

•

Facilitates direct team communication,

transparency and accountability

•

The adaptive approach lets teams respond well to

changing requirements

•

Crystal’s weaknesses include:

•

Lack of pre-defined plans can lead to scope creep

•

Lack of documentation can lead to confusion

51

6. Feature Driven Development 

(FDD)

•

originally conceived by Peter Coad as a practical process model for

object-oriented software engineering. Stephen Palmer and John

Felsing have extended and improved Coad’s work.

•

FDD adopts a philosophy that

(1) emphasizes collaboration among people on an FDD team;

(2) manages problem and project complexity using feature-based

decomposition followed by the integration of software increments,

(3) communication of technical detail using verbal, graphical, and text-based

means.

•

FDD emphasizes software quality assurance activities by encouraging

an incremental development strategy, the use of design and code

inspections, the application of software quality assurance audits the

collection of metrics, and the use of patterns.

52

FDD Cont'd…..

53

FDD Cont'd…

•

The emphasis on the definition of features provides the following benefits:

 1) Because features are small blocks of deliverable functionality, users

can describe them more easily; understand how they relate to one

another more readily; and better review them for ambiguity, error, or

omissions.

2) Features can be organized into a hierarchical business-related

grouping.

3) Since a feature is the FDD deliverable software increment, the team

develops operational features every two weeks.

4) Because features are small, their design and code representations are

easier to inspect effectively.

5) Project planning, scheduling, and tracking are driven by the feature

hierarchy, rather than an arbitrarily adopted software engineering task

set.

54

FDD Cont'd…

•

Coad and his colleagues [Coa99] suggest the following template for

defining a feature:

     <action> 

the 

<result> <by for of to> 

a(n) 

<object>

where an 

<object> 

is “a person, place, or thing (including roles,

moments in time or intervals of time, or catalog-entry-like

descriptions).”

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

Add the product to shopping cart

Display the technical-specifications of the product

Store the shipping-information for the customer

55

7. Lean Software Development 

(LSD)

•

Works on the lean principles that inspire the LSD process can be

summarized as 

eliminate waste, build quality in, create knowledge, defer

commitment, deliver fast, respect people, and optimize the whole

.

•

Each of these principles can be adapted to the software process. For

example,

•

eliminate waste 

within the context of an agile software project can be

interpreted to mean

(1) adding no extraneous features or functions,

(2) assessing the cost and schedule impact of any newly requested requirement,

(3) removing any superfluous process steps,

(4) establishing mechanisms to improve the way team members find information,

(5) ensuring the testing finds as many errors as possible,

(6) reducing the time required to request and get a decision that affects the software

or the process that is applied to create it

 (7) streamlining the manner in which information is transmitted to all stakeholders

involved in the process.

56

8. Agile Modelling (AM):

•

The scope and complexity of such systems must be modeled so that

•

All constituencies can better understand what needs to be accomplished,

•

The problem can be partitioned effectively among the people who can solve it,

•

Quality can be assessed as the system is being engineered and built.

•

Model with a purpose. 

A developer who uses AM should have a specific

goal in mind before creating the model.

•

Use multiple models.

•

Travel light. 

As software engineering work proceeds, keep only those

models that will provide long-term value.

•

Content is more important than representation. 

Modeling should impart

information to its intended audience.

•

Know the models and the tools you use to create them. 

Understand the

strengths and weaknesses of each model and the tools.

•

Adapt locally. 

The modeling approach should be adapted to the needs of

the agile team.

57

9. 

Agile Unified Process 

(AUP):

•

Within each of the activities, the team iterates to achieve agility and to deliver

meaningful software increments to end users as rapidly as possible.

•

Modeling

. 

UML representations of the business and problem domains are

created.

•

Implementation

. 

Models are translated into source code.

•

Testing

. 

Like XP, the team designs and executes a series of tests to uncover errors

and ensure that the source code meets its requirements.

•

Deployment

. D

elivery of a software increment and the acquisition of feedback

from end users.

•

Configuration and project management

. 

In the context of AUP, configuration

management addresses change management, risk management, and the control

of any persistent work products that are produced by the team. Project

management tracks and controls the progress of the team and coordinates team

activities.

•

Environment management

. 

Environment management coordinates a process

infrastructure that includes standards, tools, and other support technology

available to the team.

58

T

e

s

t

-

d

r

i

v

e

n

d

e

v

e

l

o

p

m

e

n

t

/

c

o

n

t

i

n

u

o

u

s

i

n

t

e

g

r

a

t

i

o

n

i

n

D

e

v

O

p

s

•

Test-driven development

 (

TDD

) is a software development

process relying on software requirements being converted to test

cases before software is fully developed, and tracking all software

development by repeatedly testing the software against all test cases.

This is opposed to software being developed first and test cases

created later.

•

Continuous integration (CI) 

is the practice of automating the

integration of code changes from multiple contributors into a single

software project. It’s a primary DevOps best practice, allowing

developers to frequently merge code changes into a central

repository where builds and tests then run. Automated tools are used

to assert the new code’s correctness before integration.

59

Pair Programming,  refactoring:

•

Pair programming

 is an agile software development technique in which

two programmers work together at one workstation. One, the 

driver

,

writes code while the other, the 

observer

 or 

navigator

, reviews each line of

code as it is typed in. The two programmers switch roles frequently.

•

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.

•

Refactoring is the process of changing a software system in such a way that

it does not alter the external behavior of the code yet improves the

internal structure. It is a disciplined way to clean up code [and

modify/simplify the internal design] that minimizes the chances of

introducing bugs. In essence, when you refactor you are improving the

design of the code after it has been written.

60

Unit-1

Concludes……

61