Software Engineering 10IS51

UNIT –6
Development

Rapid Software Development

Because of rapidly changing business environments, businesses have to

respond to new opportunities and competition. This requires software and
rapid development and delivery is not often the most critical requirement for
software systems. Businesses may be willing to accept lower quality software
if rapid delivery of essential functionality is possible.

Requirements
Because of the changing environment, it is often impossible to arrive at a
stable, consistent set of system requirements. Therefore a waterfall model of
development is impractical and an approach to development based on iterative
specification and delivery is the only way to deliver software quickly.

Characteristics of RAD processes

• The processes of specification, design and implementation are
concurrent. There is no detailed specification and design documentation
is minimized.
• The system is developed in a series of increments. End users evaluate
each increment and make proposals for later increments.
• System user interfaces are usually developed using an interactive
development system.

An iterative development process

Advantages of incremental development

• Accelerated delivery of customer services. Each increment delivers the
highest priority functionality to the customer.

Department of CSE, SJBIT Page 50

Software Engineering 10IS51

• User engagement with the system. Users have to be involved in the

development which means the system is more likely to meet their
requirements and the users are more committed to the system.

Problems with incremental development

• Management problems: Progress can be hard to judge and problems hard to
find because there is no documentation to demonstrate what has been done.
• Contractual problems: The normal contract may include a specification;
without a specification, different forms of contract have to be used.
• Validation problems: Without a specification, what is the system being tested
against?
• Maintenance problems: Continual change tends to corrupt software structure
making it more expensive to change and evolve to meet new requirements.

Prototyping
For some large systems, incremental iterative development and delivery may
be impractical; this is especially true when multiple teams are working on
different sites.
Prototyping, where an experimental system is developed as a basis for
formulating the requirements may be used. This system is thrown away when
the system specification has been agreed .

Incremental development and prototyping

Conflicting objectives
The objective of incremental development is to deliver a working system to
end-users. The development starts with those requirements which are best
understood.
The objective of throw-away prototyping is to validate or derive the system
requirements. The prototyping process starts with those requirements which
are poorly understood.
Agile methods
• Dissatisfaction with the overheads involved in design methods led to the
creation of agile methods. These methods:
• Focus on the code rather than the design;
• Are based on an iterative approach to software development;

Department of CSE, SJBIT Page 51

Software Engineering 10IS51

• Are intended to deliver working software quickly and evolve this quickly
to meet changing requirements.
• Agile methods are probably best suited to small/medium-sized business
systems or PC products.

Principles of agile methodsI

P rin c ip le D e s c r i p t io n

C u s to m e r in v o l v e m e n t T h e c u s t o m e r s h o u ld b e c l o s e l y i n v o l v e d t h r o u g h o u t t h e
d e v e l o p m e n t p r o c e s s . T h e i r r o l e i s p r o v i d e a n d p r i o r it i s e n e w
s y s t e m r e q u ir e m e n t s a n d t o e v a l u a t e t h e i t e r a t i o n s o f t h e s y s t e m .

Incrementaldelivery T h e s o f t w a r e i s d e v e l o p e d i n i n c r e m e n t s w i th t h e c u s t o m e r
s p e c i f y i n g t h e r e q u i r e m e n t s t o b e in c l u d e d i n e a c h i n c r e m e n t .

People not process T h e s k i l l s o f t h e d e v e l o p m e n t te a m s h o u l d b e r e c o g n i s e d a n d

e x p lo ite d . T h e t e a m s h o u l d b e l e f t t o d e v e l o p t h e i r o w n w a y s o f
working withoutprescriptive processes.

E m brace change E x p e c t t h e s y s t e m r e q u i r e m e n t s t o c h a n g e a n d d e s i g n th e s y s t e m
s o th a t i t c a n a c c o m m o d a t e t h e s e c h a n g e s .

Maintainsimplicity F o c u s o n s i m p l i c i ty i n b o t h t h e s o f t w a r e b e i n g d e v e l o p e d a n d i n
t h e d e v e l o p m e n t p r o c e s s u s e d . W h e r e v e r p o s s i b le , a c t i v e l y w o r k
to e l i m i n a t e c o m p le x i t y f r o m th e s y s t e m .

Problems with agile methods

• It can be difficult to keep the interest of customers who are involved in
the process.
• Team members may be unsuited to the intense involvement that
characterizes agile methods.
• Prioritizing changes can be difficult where there are multiple
stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other approaches to iterative
development.

Extreme programming
• Perhaps the best-known and most widely used agile method.
• Extreme Programming (XP) takes an ‘extreme’ approach to iterative
development.
• New versions may be built several times per day;
• Increments are delivered to customers every 2 weeks;
• All tests must be run for every build and the build is only accepted if
tests run successfully.

Department of CSE, SJBIT Page 52

Software Engineering 10IS51

The XP release cycle

I

Extreme programming practices 1

I ncr em en tal p lan n in g R equire m en ts are re cord ed on Sto ry C ar ds and the Stories to be
included in a re le ase are determ ined b y th e tim e availab le a n d
their relative prior ity. T he deve lope rs br eak the se S tor ies into
deve lop m en t ŌT as ksÕ.
S m all R elease s T he m in im al u seful s et o f func tiona lity tha t prov ides b u siness
va lue is de ve lo ped fir st. R eleas es of the system are frequen t and
increm en tally a dd func tiona lity to the first relea se.
S im ple D esign E nough de sign is car ried ou t to m eet the cu r ren t requ irem en ts
an d no m o r e.
T est first deve lop m en t A n au to m ated un it tes t fr am ew o rk is u sed to wr ite tes ts for a ne w
p iece of func tiona lity be for e tha t fun ction ality itse lf is
im plem en ted .
R efactorin g A ll d e velope rs are ex pe c ted to refacto r the code con tinuo us ly as
so on as p o s sib le code im pr ove m en ts are fou nd. T h is keep s the
co de sim ple an d m ain tainab le.

Department of CSE, SJBIT Page 53

Software Engineering 10IS51

Extreme programming practices 2

Pair Programming Developers work in pairs, checking each otherÕs work and
providing the support to always do a good job.
Collective Ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers own all the
code. Anyone can change anything.
Continuous Integration As soon as work on a task is complete it is integrated into the
whole system. After any such integration, all the unit tests in the
system must pass.
Sustainable pace Large amounts of over-time are not considered acceptable as the
net effect is often to reduce code qua lity and medium term
productivity
On-site Customer A representative of the end-user of the system (the Customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.

XP and agile principles

• Incremental development is supported through small, frequent system
releases.
• Customer involvement means full-time customer engagement with the
team.
• People not process through pair programming, collective ownership and
a process that avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of code.

Requirements scenarios
• In XP, user requirements are expressed as scenarios or user stories.
• These are written on cards and the development team breaks them down
into implementation tasks. These tasks are the basis of schedule and cost
estimates.
• The customer chooses the stories for inclusion in the next release based
on their priorities and the schedule estimates.

Department of CSE, SJBIT Page 54

Software Engineering 10IS51

Story card for document downloading

XP and change
• Conventional wisdom in software engineering is to design for change. It
is worth spending time and effort anticipating changes as this reduces
costs later in the life cycle.
• XP, however, maintains that this is not worthwhile as changes cannot be
reliably anticipated.
• Rather, it proposes constant code improvement (refactoring) to make
changes easier when they have to be implemented

Testing in XP
• Test-first development. Incremental test development from scenarios.
• User involvement in test development and validation.
• Automated test harnesses are used to run all component tests each time
that a new release is built.
Test case description

Department of CSE, SJBIT Page 55

Software Engineering 10IS51

Test-first development
• Writing tests before code clarifies the requirements to be implemented.
• Tests are written as programs rather than data so that they can be
executed automatically. The test includes a check that it has executed
correctly.
• All previous and new tests are automatically run when new functionality
is added. Thus checking that the new functionality has not introduced
errors.

Pair programming
In XP, programmers work in pairs, sitting together to develop code. This helps
develop common ownership of code and spreads knowledge across the team.
It serves as an informal review process as each line of code is looked at by
more than 1 person. It encourages refactoring as the whole team can benefit
from this. Measurements suggest that development productivity with pair
programming is similar to that of two people working independently.

Rapid application development

Agile methods have received a lot of attention but other approaches to rapid
application development have been used for many years.
These are designed to develop data-intensive business applications and rely on
programming and presenting information from a database.

RAD environment tools

• Database programming language
• Interface generator
• Links to office applications
• Report generators

A RAD environment

Department of CSE, SJBIT Page 56

Software Engineering 10IS51

Interface generation
• Many applications are based around complex forms and developing
these forms manually is a time-consuming activity.
• RAD environments include support for screen generation including:
• Interactive form definition using drag and drop techniques;
• Form linking where the sequence of forms to be presented is specified;
• Form verification where allowed ranges in form fields are defined.

Visual programming
• Scripting languages such as Visual Basic support visual programming
where the prototype is developed by creating a user interface from
standard items and associating components with these items
• A large library of components exists to support this type of development
• These may be tailored to suit the specific application requirements.

Visual programming with reuse

Problems with visual development

Difficult to coordinate team-based development. No explicit system
architecture. Complex dependencies between parts of the program can cause
maintainability problems.

COTS reuse
• An effective approach to rapid development is to configure and link
existing off the shelf systems. For example, a requirements management
system could be built by using:
• A database to store requirements;
• A word processor to capture requirements and format reports;
• A spreadsheet for traceability management;

Department of CSE, SJBIT Page 57

Software Engineering 10IS51

Compound documents
For some applications, a prototype can be created by developing a compound
document. This is a document with active elements (such as a spreadsheet)
that allow user computations. Each active element has an associated
application which is invoked when that element is selected. The document
itself is the integrator for the different applications.

Application linking

Software prototyping
• A prototype is an initial version of a system used to demonstrate
concepts and try out design options.
A prototype can be used in:
• The requirements engineering process to help with requirements
elicitation and validation;
• In design processes to explore options and develop a UI design;
• In the testing process to run back-to-back tests.

Benefits of prototyping
• Improved system usability.
• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.

Department of CSE, SJBIT Page 58

Software Engineering 10IS51

Back to back testing

The prototyping process

Throw-away prototypes
• Prototypes should be discarded after development as they are not a good
basis for a production system:
• It may be impossible to tune the system to meet non-functional
requirements;
• Prototypes are normally undocumented;
• The prototype structure is usually degraded through rapid change;
• The prototype probably will not meet normal organizational quality
standards.
Software evolution
Software change
• Software change is inevitable
• New requirements emerge when the software is used;
• The business environment changes;
• Errors must be repaired;
• New computers and equipment is added to the system;
• The performance or reliability of the system may have to be improved.
• A key problem for organisations is implementing and managing
change to their existing software systems

Department of CSE, SJBIT Page 59

 Software Engineering 17CS45

MODULE 4
CHAPTER 2: SOFTWARE EVOLUTION

Once a system has been deployed, it inevitably has to change if it is to remain useful. There are
many reasons why software change is inevitable
 As business changes and changes to user expectations generate new requirements for
the existing software
 Parts of the software may have to be modified to correct errors that are found in
operation,
 To adapt changes to its hardware and software platform
 To improve its performance or other non-functional characteristics

A key problem for all organizations is implementing and managing change to their existing
software systems.
 Organizations have huge investments in their software systems - they are critical
business assets. To maintain the value of these assets to the business, they must be
changed and updated. The majority of the software budget in large companies is devoted
to changing and evolving existing software rather than developing new software.

A spiral model of development and evolution represents how a software system evolves
through a sequence of multiple releases. (Figure 1)

Figure 1: A spiral model of development and evolution

1 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru

 Software Engineering 17CS45

Figure 2 shows the alternative view of the software evolution life cycle. In this model, they
distinguish between evolution and servicing.
 Evolution: The stage in a software system’s life cycle where it is in operational use and
is evolving as new requirements are proposed and implemented in the system.
 Servicing: At this stage, the software remains useful but the only changes made are
those required to keep it operational i.e. bug fixes and changes to reflect changes in the
software’s environment. No new functionality is added.
 Phase-out: The software may still be used but no further changes are made to it.

Figure 2: Evolution and servicing

2.1 Evolution processes

 Software evolution processes vary depending on the type of software being maintained,
the development processes used in an organization and the skills of the people involved.
 System change proposals are the driver for system evolution in all organizations.
Change proposals may come from existing requirements that have not been
implemented in the released system, requests for new requirements, bug reports from
system stakeholders, and new ideas for software improvement from the system
development team.
 The processes of change identification and system evolution are cyclic and continue
throughout the lifetime of a system as shows in Figure 3.

Figure 3: Change identification and evolution processes

2 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru

 Software Engineering 17CS45

The software evolution process

 Figure 4 shows an overview of the evolution process. The process includes the
fundamental activities of change analysis, release planning, system implementation, and
releasing a system to customers.
 If the proposed changes are accepted, a new release of the system is planned.
 During release planning, all proposed changes such as fault repair, adaptation, and new
functionality are considered.
 A decision is then made on which changes to implement in the next version of the
system. The changes are implemented and validated, and a new version of the system is
released.
 The process then iterates with a new set of changes proposed for the next release.

Figure 4: The software evolution process

 The Change implementation stage should modify the system specification, design, and
implementation to reflect the changes to the system which is shown in Figure 5.
 New requirements that reflect the system changes are proposed, analyzed, and validated.
System components are redesigned and implemented and the system is retested.

Figure 5: Change Implementation

Change requests arise for three reasons:

1. If a serious system fault occurs that has to be repaired.
2. If changes to the systems operating environment have unexpected effects that disrupt
normal operation.
3. If there are unanticipated changes to the business running the system

3 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru

 Software Engineering 17CS45

 To make the change quickly means that you may not be able to follow the formal
change analysis process. Rather than modify the requirements and design, make an
emergency fix to the program to solve the immediate problem (Figure 6).

Figure 6: The emergency repair process

2.2 Program Evolution Dynamics

 Program evolution dynamics is the study of system change.

 After several major empirical studies, Lehman and Belady proposed that there were a
number of 'laws' which apply to all systems as they evolved.They are applicable to large
systems developed by large organizations.

Figure: Lehman’s laws

4 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru

 Software Engineering 17CS45

 The first law states that system maintenance is an inevitable process.

 The second law states that, as a system is changed, its structure is degraded.
 The third law states that the system size, time between releases and system errors are
invariant for each system release
 Lehman’s fourth law suggests that most large programming projects work in a
‘saturated’ state. That is, a change to resources or staffing has invisible effects on the
long-term evolution of the system.
 Lehman’s fifth law is concerned with the change increments in each system release.
Adding new functionality to a system inevitably introduces new system faults. The more
functionality added in each release, the more faults there will be.
 The sixth and seventh laws are similar and essentially say that users of software will
become increasingly unhappy with it unless it is maintained and new functionality is
added to it.

2.3 Software Maintenance

 Software maintenance focuses on modifying a program after it has been put into use.
 The term is mostly used for changing custom software. Generic software products are
said to evolve to create new versions.
 Maintenance does not normally involve major changes to the system's architecture.
Changes are implemented by modifying existing components and adding new
components to the system.

There are three different types of software maintenance

1. Fault repairs: Coding errors are usually relatively cheap to correct. Design errors are
more expensive as they may involve rewriting several program components.
Requirements errors are the most expensive to repair because of the extensive system
redesign which may be necessary.
2. Environmental adaptation: When the system’s environment such as the hardware, the
platform operating system, or other support software changes, this types of maintenance
is required. The application system must be modified to adapt it to cope with these
environmental changes.
3. Functionality addition: This type of maintenance is necessary when the system
requirements change in response to organizational or business change.

5 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru

 Software Engineering 17CS45

Figure 8: Maintenance effort distribution

Figure 9 shows how overall lifetime costs may decrease as more effort is expended during
system development to produce a maintainable system. Because of the potential reduction in
costs of understanding, analysis, and testing, there is a significant multiplier effect when the
system is developed for maintainability.

Figure 9: Development and maintenance costs

For System 1, extra development costs of $25,000 are invested in making the system more
maintainable. This results in a savings of $100,000 in maintenance costs over the lifetime of
the system. This assumes that a percentage increase in development costs results in a
comparable percentage decrease in overall system costs.

The reasons for more expensive Maintenance cost include factors such as:

1. Team stability: After a system has been delivered, the development team to be broken
up and for people to work on new projects. The new team or the individuals responsible
for system maintenance do not understand the system or the background to system
design decisions. They need to spend time understanding the existing system before
implementing changes to it.
2. Poor development practice: The contract to maintain a system is usually separate from
the system development contract. Lack of team stability, if there is no incentive for a
development team to write maintainable software and if a development team cut corners
to save effort during development then software is more difficult to change in the future.

6 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru

 Software Engineering 17CS45

3. Staff skills: Maintenance staff are relatively inexperienced and unfamiliar with the
application domain.
4. Program age and structure: as programs age, their structure is degraded and they
become harder to understand and change.

2.3.1 Maintenance prediction

Maintenance prediction is concerned with what system changes might be proposed and what
parts of the system are likely to be the most difficult to maintain and to estimate the overall
maintenance costs for a system in a given time period.

Figure 10 shows these predictions and associated questions.

Figure 10: Maintenance prediction

To evaluate the relationships between a system and its environment, assess the following:
1. The number and complexity of system interfaces:
2. The number of inherently volatile system requirements:
3. The business processes in which the system is used

Predictions of maintainability can be made by assessing the complexity of system components.

Studies have shown that most maintenance effort is spent on a relatively small number of
system components. Complexity depends on:
1. Complexity of control structures
2. Complexity of data structures
3. Object, method (procedure) and module size.

7 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru

 Software Engineering 17CS45

Process metrics may be used to assess maintainability are as follows:

1. Number of requests for corrective maintenance: An increase in the number of bug

and failure reports may indicate that more errors are being introduced into the program
than are being repaired during the maintenance process.
2. Average time required for impact analysis: This reflects the number of program
components that are affected by the change request. If this time increases, it implies
more and more components are affected and maintainability is decreasing.
3. Average time taken to implement a change request: This is the amount of time need
to modify the system and its documentation. An increase in the time needed to
implement a change may indicate a decline in maintainability.
4. Number of outstanding change requests: An increase in this number over time may
imply a decline in maintainability.

2.3.2 Software Reengineering

Reengineering involves re-documenting the system, refactoring the system architecture,

translating programs to a modern programming language, modifying and updating the
structure, and values of the system’s data.

There are two important benefits from reengineering rather than replacement.
1. Reduced risk: there is a high risk in new software development. There may be
development problems, staffing problems and specification problems.
2. Reduced cost: the cost of reengineering is significantly less than the costs of developing
new software.

Figure 11: The reengineering process

8 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru

 Software Engineering 17CS45

Figure11 is a general model of the reengineering process. The input to the process is a legacy
program and the output is an improved and restructured version of the same program.

The activities in reengineering process are as follows:

1. Source code translation: Using a translation tool, the program is converted from an old
programming language to a more modern version of the same language or to a different
language.
2. Reverse engineering: The program is analyzed and information extracted from it. This
helps to document its organization and functionality.
3. Program structure improvement: The control structure of the program is analyzed
and modified to make it easier to read and understand. This can be partially automated
but some manual intervention is usually required.
4. Program modularization: Related parts of the program are grouped together and,
where appropriate, redundancy is removed and architectural refactoring may be
involved. This is a manual process.
5. Data reengineering: The data processed by the program is changed to reflect program
changes and clean up the data.

The costs of reengineering depend on the extent of the work that is carried out. There is a
spectrum of possible approaches to reengineering, as shown in Figure 12.

Figure 12: Reengineering approaches

9 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru

 Software Engineering 17CS45

2.3.3 Preventative maintenance by refactoring

 Refactoring is the process of making improvements to a program to slow down

degradation through change. Refactoring could be assumed as 'preventative
maintenance' that reduces the problems of future change.
 Refactoring involves modifying a program to improve its structure, reduce its
complexity or make it easier to understand. When you refactor a program, you should
not add functionality but rather concentrate on program improvement.
 Reengineering takes place after a system has been maintained for some time and
maintenance costs are increasing. Automated tools can be used to process and
reengineer a legacy system to create a new system that is more maintainable.
 Refactoring is a continuous process of improvement throughout the development and
evolution process. It is intended to avoid the structure and code degradation that
increases the costs and difficulties of maintaining a system.

'Bad smells' of code are stereotypical situations in which the code of a program can be improved
through refactoring:

1. Duplicate code: The same of very similar code may be included at different places in a
program. This can be removed and implemented as a single method or function that is
called as required.
2. Long methods: If a method is too long, it should be redesigned as a number of shorter
methods.
3. Switch (case) statements: These often involve duplication, where the switch depends
on the type of some value. The switch statements may be scattered around a program.
In object-oriented languages, polymorphism can be used to achieve the same thing.
4. Data clumping: Data clumps occur when the same group of data items reoccur in
several places in a program. These can be replaced with an object encapsulating all of
the data.
5. Speculative generality: This occurs when developers include generality in a program
in case it is required in future. This can often simply be removed.

10 Deepak D, Asst. Prof., Dept. of CS&E, Canara Engineering College, Mangaluru