RV Institute of Technology and Management®

RV Educational Institutions®
RV Institute of Technology and
Management
(Affiliated to VTU, Belagavi)

JP Nagar 8th Phase, Bengaluru - 560076

DEPARTMENT OF ISE AND CSE

Course Name: Software Engineering & Project Management

Course Code: BCS501

V Semester
2022 Scheme
 RV Institute of Technology and Management®

CHAPTER 1

1.1 THE NATURE OF SOFTWARE

Today, software takes on a dual role. It is a product, and at the same time, the vehicle
for delivering a product. As a product, it delivers the computing potential embodied by
computer hardware or more broadly, by a network of computers that are accessible by
local hardware. Whether it resides within a mobile phone or operates inside a
mainframe computer, software is an information transformer—producing, managing,
acquiring, modifying, displaying, or transmitting information that can be as simple as
a single bit or as complex as a multimedia presentation derived from data acquired
from dozens of independent sources. As the vehicle used to deliver the product,
software acts as the basis for the control of the computer (operating systems), the
communication of information (networks), and the creation and control of other
programs (software tools and environments).

Software delivers the most important product of our time—information. It transforms

personal data (e.g., an individual’s financial transactions) so that the data can be more
useful in a local context; it manages business information to enhance competitiveness;
it provides a gateway to worldwide information networks (e.g., the Internet), and
provides the means for acquiring information in all of its forms.

The role of computer software has undergone significant change over the last half-
century. Dramatic improvements in hardware performance, profound changes in
computing architectures, vast increases in memory and storage capacity, and a wide
variety of exotic input and output options, have all precipitated more sophisticated and
complex computer-based systems. Sophistication and complexity can produce
dazzling results when a system succeeds, but they can also pose huge problems for
those who must build complex systems.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Today, a huge software industry has become a dominant factor in the economies of the
industrialized world. Teams of software specialists, each focusing on one part of the
technology required to deliver a complex application, have replaced the lone
programmer of an earlier era. And yet, the questions that were asked of the lone

programmer are the same questions that are asked when modern computer-based
systems are built:.”

• Why does it take so long to get software finished? • Why are development costs so high?

• Why can’t we find all errors before we give the software to our customers?

• Why do we spend so much time and effort maintaining existing programs?

• Why do we continue to have difficulty in measuring progress as software is being developed

and maintained?
1.1.1 DEFINING SOFTWARE

Software is: (1) instructions (computer programs) that when executed provide desired
features, function, and performance;

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

(3) descriptive information in both hard copy and virtual forms that describes the operation
and use of the programs.

software has characteristics that are considerably different than those of hardware:

1. Software is developed or engineered; it is not manufactured in the classical sense. Although

some similarities exist between software development and hardware manufacturing,
the two activities are fundamentally different. In both activities, high quality is

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

achieved through good design, but the manufacturing phase for hardware can introduce
quality problems that are nonexistent (or easily corrected) for software. Both activities
are dependent on people, but the relationship between people applied and work
accomplished is entirely different. Both activities require the construction of a
“product,” but the approaches are different. Software costs are concentrated in
engineering. This means that software projects cannot be managed as if they were
manufacturing projects.

2. Software doesn’t “wear out.”

Figure depicts failure rate as a function of time for hardware. The relationship, often
called the “bathtub curve,” indicates that hardware exhibits relatively high failure rates
early in its life (these failures are often attributable to design or manufacturing defects);
defects are corrected and the failure rate drops to a steady-state level (hopefully, quite
low) for some period of time. As time passes, however, the failure rate rises again as
hardware components suffer from the cumulative effects of dust, vibration, abuse,
temperature extremes, and many other environmental maladies. Stated simply, the
hardware begins to wear out.

Software is not susceptible to the environmental maladies that cause hardware to wear
out. In theory, therefore, the failure rate curve for software should take the form of the
“idealized curve” shown in Figure Undiscovered defects will cause high failure rates
early in the life of a program. However, these are corrected and the curve flattens as
shown. The idealized curve is a gross oversimplification of actual failure models for
software. However, the implication is clear—software doesn’t wear out. But it does
deteriorate!

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

FIG 1.1: Failure curves for software

This seeming contradiction can best be explained by considering the actual curve in
Figure During its life, software will undergo change. As changes are made, it is likely
that errors will be introduced, causing the failure rate curve to spike as shown in the
“actual curve” Figure. Before the curve can return to the original steady-state failure
rate, another change is requested, causing the curve to spike again. Slowly, the
minimum failure rate level begins to rise—the software is deteriorating due to change.

Another aspect of wear illustrates the difference between hardware and software.
When a hardware component wears out, it is replaced by a spare part. There are no
software spare parts. Every software failure indicates an error in design or in the
process through which design was translated into machine executable code. Therefore,
the software maintenance tasks that accommodate requests for change involve
considerably more complexity than hardware maintenance.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

3. Although the industry is moving toward component-based construction, most software

continues to be custom built.

As an engineering discipline evolves, a collection of standard design components is

created. Standard screws and off-the-shelf integrated circuits are only two of thousands
of standard components that are used by mechanical and electrical engineers as they
design new systems. The reusable components have been created so that the engineer
can concentrate on the truly innovative elements of a design, that is, the parts of the
design that represent something new. In the hardware world, component reuse is a
natural part of the engineering process. In the software world, it is something that has
only begun to be achieved on a broad scale.

Seven broad categories of computer software present continuing challenges for software
engineers:

System software—a collection of programs written to service other programs. Some

system software (e.g., compilers, editors, and file management utilities) processes
complex, but determinate, information structures. Other systems applications (e.g.,
operating system components, drivers, networking software, telecommunications
processors) process largely indeterminate data. In either case, the systems software
area is characterized by heavy interaction with computer hardware; heavy usage by
multiple users; concurrent operation that requires scheduling, resource sharing, and
sophisticated process management; complex data structures; and multiple external
interfaces.

Application software—stand-alone programs that solve a specific business need.

Applications in this area process business or technical data in a way that facilitates
business operations or management/technical decision making. In addition to
conventional data processing applications, application software is used to control
business functions in real time (e.g., point-of-sale transaction processing, real-time
manufacturing process control).

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Engineering/scientific software—has been characterized by “number crunching”

algorithms. Applications range from astronomy to volcanology, from automotive stress
analysis to space shuttle orbital dynamics, and from molecular biology to automated
manufacturing. However, modern applications within the engineering/scientific area
are moving away from conventional numerical algorithms. Computer-aided design,
system simulation, and other interactive applications have begun to take on real-time
and even system software characteristics.

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. Embedded
software can perform limited and esoteric functions (e.g., key pad control for a
microwave oven) or provide significant function and control capability (e.g., digital
functions in an automobile such as fuel control, dashboard displays, and braking
systems).

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,
database management, and personal and business financial applications).

Web applications—called “WebApps,” this network-centric software category spans

a wide array of applications. In their simplest form, WebApps can be little more than
a set of linked hypertext files that present information using text and limited graphics.
However, as Web 2.0 emerges, 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.

Artificial intelligence software—makes use of nonnumerical algorithms to solve

complex problems that are not amenable to computation or straightforward analysis.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Applications within this area include robotics, expert systems, pattern recognition
(image and voice), artificial neural networks, theorem proving, and game playing.

1.1.2 LEGACY SOFTWARE

Hundreds of thousands of computer programs fall into one of the seven broad
application domains discussed in the preceding subsection. Some of these are stateof-
the-art software—just released to individuals, industry, and government. But other
programs are older, in some cases much older.

These older programs—often referred to as legacy software—have been the focus of

continuous attention and concern since the 1960s. Dayani-Fard and his colleagues
[Day99] describe legacy software in the following way

Legacy software systems . . . were developed decades ago and have been continually
modified to meet changes in business requirements and computing platforms. The
proliferation of such systems is causing headaches for large organizations who find
them costly to maintain and risky to evolve.

Liu and his colleagues [Liu98] extend this description by noting that “many legacy
systems remain supportive to core business functions and are ‘indispensable’ to the
business.” Hence, legacy software is characterized by longevity and business
criticality.

Unfortunately, there is sometimes one additional characteristic that is present in legacy

software—poor quality. Legacy systems sometimes have inextensible designs,
convoluted code, poor or nonexistent documentation, test cases and results that were
never archived, a poorly managed change history—the list can be quite long. And yet,
these systems support “core business functions and are indispensable to the business.”
What to do? The only reasonable answer may be: Do nothing, at least until the legacy
system must undergo some significant change. If the legacy software meets the needs
of its users and runs reliably, it isn’t broken and does not need to be fixed. However,
as time passes, legacy systems often evolve for one or more of the following reasons:

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

• The software must be adapted to meet the needs of new computing environments or
technology.

• The software must be enhanced to implement new business requirements.

• The software must be extended to make it interoperable with other more modern systems or
databases.

• The software must be re-architected to make it viable within a network environment

Definition: Beliefs about software and the process used to build it. Myths have number of attributes
that have made them insidious (i.e. dangerous).
• Misleading Attitudes - caused serious problem for managers and technical people.
Management myths
Managers in most disciplines, are often under pressure to maintain budgets, keep schedules on time,
and improve quality.
Myth1: 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 :
• Are software practitioners aware of existence standards?
• Does it reflect modern software engineering practice?
• Is it complete? Is it streamlined to improve time to delivery while still maintaining a focus on
quality?

Myth2: If we get behind schedule, we can add more programmers and catch up
Reality: Software development is not a mechanistic process like manufacturing. Adding people to a
late software project makes it later.
• People can be added but only in a planned and well-coordinated manner

Myth3: If I decide to outsource the software project to a third party, I can just relax and let that firm
build it.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Reality: If an organization does not understand how to manage and control software projects
internally, it will invariably struggle when it outsource software projects

Customer Myths
Customer may be a person from inside or outside the company that has requested software under
contract.
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 information domain, function, behavior, performance, interfaces, design
constraints, and validation criteria is essential. These characteristics can be determined only after
thorough communication between customer and developer.
Myth: Project requirements continually change, but change can be easily accommodated because
software is flexible.
Reality: Customer can review requirements and recommend modifications with relatively little
impact on cost. When changes are requested during software design, the cost impact grows rapidly.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Practitioner's myths
Myth1: Once we write the program and get it to work, our job is done.
Reality: Someone once said that "the sooner you begin 'writing code', the longer it'll take you to get
done." Industry data indicate that between 60 and 80 percent of all effort expended on software will
be expended after it is delivered to the customer for the first time.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

1.2 PROCESS FRAMEWORK

FIG 1.2: A software process framework

Generic process framework for software engineering defines five framework activities—
communication, planning, modeling, construction, and deployment. In addition, a set of umbrella
activities—project tracking and control, risk management, quality assurance, configuration
management, technical reviews, and others—are applied throughout the process
process flow—describes how the framework activities and the actions and tasks that occur within
each framework activity are organized with respect to sequence and time

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

1.2.1 PROCESS FLOW

Fig 1.3: Process flow

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Fig a represents an iterative process flow repeats one or more of the activities before
proceeding to the next

Figure b represents an evolutionary process flow executes the activities in a “circular”

manner. Each circuit through the five activities leads to a more complete version of the
software

Figure c represents parallel process flow, Figure d represents an executes one or more
activities in parallel with other activities (e.g., modeling for one aspect of the software
might be executed in parallel with construction of another aspect of the software)

1.3 PROCESS PATTERNS

Every software team encounters problems as it moves through the software process. It would be
useful if proven solutions to these problems were readily available to the team so that the problems
could be addressed and resolved quickly. A process pattern describes a process-related problem
that is encountered during software engineering work, identifies the environment in which the
problem has been encountered, and suggests one or more proven solutions to the problem. Stated
in more general terms, a process pattern provides you with a template—a consistent method for
describing problem solutions within the context of the software process. By combining patterns, a
software team can solve problems and construct a process that best meets the needs of a project

Ambler has proposed a template for describing a process pattern:

Pattern Name. The pattern is given a meaningful name describing it within the context
of the software process (e.g., Technical Reviews). Forces. The environment in which
the pattern is encountered and the issues that make the problem visible and may affect
its solution.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Type. The pattern type is specified. Ambler [Amb98] suggests three types

1. Stage pattern—defines a problem associated with a framework activity for the process. Since
a framework activity encompasses multiple actions and work tasks, a stage pattern incorporates
multiple task patterns. An example of a stage pattern might be Establishing Communication. This
pattern would incorporate the task pattern Requirements Gathering and others.

2. Task pattern—defines a problem associated with a software engineering action or work task
and relevant to successful software engineering practice (e.g., Requirements Gathering is a task
pattern).

3. Phase pattern—define the sequence of framework activities that occurs within the process,
even when the overall flow of activities is iterative in nature. An example of a phase pattern might
be Spiral Model or Prototyping

Initial context. Describes the conditions under which the pattern applies. Prior to the initiation of
the pattern:

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

(2) What is the entry state for the process?

(3) What software engineering information or project information already exists?

For example, the Planning pattern (a stage pattern) requires that

(1) customers and software engineers have established a collaborative communication;

(2) successful completion of a number of task patterns [specified] for the Communication pattern
has occurred; and

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

(3) the project scope, basic business requirements, and project constraints are known

1.4 PROCESS ASSESSMENT AND IMPROVEMENT

A number of different approaches to software process assessment and improvement have been
proposed over the past few decades: Standard CMMI Assessment Method for Process
Improvement (SCAMPI)—provides a five-step process assessment model that incorporates five
phases: initiating, diagnosing, establishing, acting, and learning. The SCAMPI method uses the
SEI CMMI as the basis for assessment [SEI00].

CMM-Based Appraisal for Internal Process Improvement (CBA IPI)— provides a diagnostic
technique for assessing the relative maturity of a software organization; uses the SEI CMM as the
basis for the assessment [Dun01].

SPICE (ISO/IEC15504)—a standard that defines a set of requirements for software process
assessment. The intent of the standard is to assist organizations in developing an objective
evaluation of the efficacy of any defined software process [ISO08].

ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to
improve the overall quality of the products, systems, or services that it provides. Therefore, the
standard is directly applicable to software organizations and companies

1.5 PERSONAL AND TEAM PROCESS MODELS

The best software process is one that is close to the people who will be doing the work. If a software
process model has been developed at a corporate or organizational level, it can be effective only if
it is amenable to significant adaptation to meet the needs of the project team that is actually doing
software engineering work. In an ideal setting, you would create a process that best fits your needs,
and at the same time, meets the broader needs of the team and the organization. Alternatively, the

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

team itself can create its own process, and at the same time meet the narrower needs of individuals
and the broader needs of the organization.

1.5.1 PERSONAL SOFTWARE PROCESS (PSP)

The Personal Software Process (PSP) emphasizes personal measurement of both the work product
that is produced and the resultant quality of the work product. In addition PSP makes the
practitioner responsible for project planning (e.g., estimating and scheduling) and empowers the
practitioner to control the quality of all software work products that are developed. The PSP model
defines five framework activities:

Planning. This activity isolates requirements and develops both size and resource estimates. In
addition, a defect estimate (the number of defects projected for the work) is made. All metrics are
recorded on worksheets or templates. Finally, development tasks are identified and a project
schedule is created.

High-level design. External specifications for each component to be constructed are developed
and a component design is created. Prototypes are built when uncertainty exists. All issues are
recorded and tracked.

High-level design review. Formal verification methods are applied to uncover errors in the
design. Metrics are maintained for all important tasks and work results.

Development. The component-level design is refined and reviewed. Code is generated, reviewed,
compiled, and tested. Metrics are maintained for all important tasks and work results.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Postmortem. Using the measures and metrics collected (this is a substantial amount of data that
should be analyzed statistically), the effectiveness of the process is determined. Measures and
metrics should provide guidance for modifying the process to improve its effectiveness

Team Software Process (TSP)

The goal of TSP is to build a “self directed” project team that organizes itself to produce high-
quality software. Humphrey [Hum98] defines the following objectives for TSP:

• Build self-directed teams that plan and track their work, establish goals, and own their processes
and plans. These can be pure software teams or integrated product teams (IPTs) of 3 to about 20
engineers.

• Show managers how to coach and motivate their teams and how to help them sustain peak
performance.

• Accelerate software process improvement by making CMM23 Level 5 behavior normal and
expected. •

 Provide improvement guidance to high-maturity organizations.

• Facilitate university teaching of industrial-grade team skills

TSP defines the following framework activities: project launch, high-level design,
implementation, integration and test, and postmortem. Like their counterparts in PSP (note that
terminology is somewhat different), these activities enable the team to plan, design, and construct
software in a disciplined manner while at the same time quantitatively measuring the process and
the product. The postmortem sets the stage for process improvements.

TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team members
in their work. “Scripts” define specific process activities (i.e., project launch, design,
implementation, integration and system testing, postmortem) and other more detailed work

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

functions (e.g., development planning, requirements development, software configuration

management, unit test) that are part of the team process

1.6 PROCESS TECHNOLOGY

Process technology tools have been developed to help software organizations analyze their current process,
organize work tasks, control and monitor progress, and manage technical quality. Process technology tools
allow a software organization to build an automated model of the process framework, task sets, and
umbrella activities

The model, normally represented as a network, can then be analyzed to determine typical workflow and
examine alternative process structures that might lead to reduced development time or cost.

Once an acceptable process has been created, other process technology tools can be used to allocate,
monitor, and even control all software engineering activities, actions, and tasks defined as part of the
process model. Each member of a software team can use such tools to develop a checklist of work tasks to
be performed, work products to be produced, and quality assurance activities to be conducted. The process
technology tool can also be used to coordinate the use of other software engineering tools that are
appropriate for a particular work task.

1.7 PRODUCT AND PROCESS

If the process is weak, the end product will undoubtedly suffer. But an obsessive overreliance on
process is also dangerous. In a brief essay written many years ago, Margaret Davis [Dav95a] makes
timeless comments on the duality of product and process:

About every ten years give or take five, the software community redefines “the problem” by
shifting its focus from product issues to process issues. Thus, we have embraced structured
programming languages (product) followed by structured analysis methods (process) followed by
data encapsulation (product) followed by the current emphasis on the Software Engineering
Institute’s Software Development Capability Maturity Model (process) [followed by object-
oriented methods, followed by agile software development].

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

While the natural tendency of a pendulum is to come to rest at a point midway between two
extremes, the software community’s focus constantly shifts because new force is applied when the
last swing fails. These swings are harmful in and of themselves because they confuse the average
software practitioner by radically changing what it means to perform the job let alone perform it
well. The swings also do not solve “the problem” for they are doomed to fail as long as product
and process are treated as forming a dichotomy instead of a duality

All of human activity may be a process, but each of us derives a sense of self-worth from those
activities that result in a representation or instance that can be used or appreciated either by more
than one person, used over and over, or used in some other context not considered. That is, we
derive feelings of satisfaction from reuse of our products by ourselves or others.

Thus, while the rapid assimilation of reuse goals into software development potentially increases
the satisfaction software practitioners derive from their work, it also increases the urgency for
acceptance of the duality of product and process. Thinking of a reusable artifact as only product
or only process either obscures the context and ways to use it or obscures the fact that each use
results in product that will, in turn, be used as input to some other software development activity.
Taking one view over the other dramatically reduces the opportunities for reuse and, hence, loses
the opportunity for increasing job satisfacti

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

CHAPTER 2

Chapter 2

PROCESS MODELS

2.1 The Waterfall Model

There are times when the requirements for a problem are well understood—when work flows from
communication through deployment in a reasonably linear fashion. This situation is sometimes
encountered when well-defined adaptations or enhancements to an existing system must be made
(e.g., an adaptation to accounting software that has been mandated because of changes to
government regulations). It may also occur in a limited number of new development efforts, but
only when requirements are well defined and reasonably stable

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

Fig 2.1: The waterfall model

The waterfall model is the oldest paradigm for software engineering. However, over the past three
decades, criticism of this process model has caused even ardent supporters to question its efficacy
. Among the problems that are sometimes encountered when the waterfall model is applied are:

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

1. Real projects rarely follow the sequential flow that the model proposes. Although the linear
model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion
as the project team proceeds

2. It is often difficult for the customer to state all requirements explicitly. The waterfall model
requires this and has difficulty A major blunder, if undetected until the working program is
reviewed, can be disadvantage accommodating the natural uncertainty that exists at the beginning
of many projects.

3. The customer must have patience. A working version of the program(s) will not be available
until late in the project time span. A major blunder, if undetected until the working program is
reviewed, can be disastrous

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Fig2.2: The V-model

A variation in the representation of the waterfall model is called the V-model

V-model depicts the relationship of quality assurance actions to the actions associated with
communication, modeling, and early construction activities. As a software team moves down the
left side of the V, basic problem requirements are refined into progressively more detailed and
technical representations of the problem and its solution. Once code has been generated, the team
moves up the right side of the V, essentially performing a series of tests (quality assurance actions)
that validate each of the models created as the team moved down the left side. In reality, there is
no fundamental difference between the classic life cycle and the V-model. The V-model provides
a way of visualizing how verification and validation actions are applied to earlier engineering
work.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

2.2 INCREMENTAL PROCESS MODELS

Fig 2.3: Incremental Process Models

The incremental model combines elements of linear and parallel process flows, the incremental
model applies linear sequences in a staggered fashion as calendar time progresses. Each linear
sequence produces deliverable “increments” of the software in a manner that is similar to the
increments produced by an evolutionary process flow.

When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features (some known, others unknown)
remain undelivered. The core product is used by the customer (or undergoes detailed evaluation).
As a result of use and/or evaluation plan is developed for the next increment.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

The plan addresses the modification of the core product to better meet the needs of the customer
and the delivery of additional features and functionality. This process is repeated following the
delivery of each increment, until the complete product is produced. The incremental process model
focuses on the delivery of an operational product with each increment. Early increments are
stripped-down versions of the final product, but they do provide capability that serves the user and
also provide a platform for evaluation by the user.

Incremental development is particularly useful when staffing is unavailable for a complete

implementation by the business deadline that has been established for the project. Early increments
can be implemented with fewer people. If the core product is well received, then additional staff
(if required) can be added to implement the next increment. In addition, increments can be planned
to manage technical risks.

2.3 EVOLUTIONARY PROCESS MODELS

Evolutionary models are iterative. They are characterized in a manner that enables you to develop
increasingly more complete versions of the software.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Fig 2.4: The prototyping paradigm

The prototyping paradigm

Often, a customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features. In other cases, the developer may be unsure of the
efficiency of an algorithm, the adaptability of an operating system, or the form that human-
machine interaction should take. In these, and many other situations, a prototyping paradigm may
offer the best approach.

Although prototyping can be used as a stand-alone process model, it is more commonly used as a
technique that can be implemented within the context of any one of the process models

Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the
actual system, and developers get to build something immediately. Yet, prototyping can be
problematic for the following reasons:

1. Stakeholders see what appears to be a working version of the software, unaware that the
prototype is held together haphazardly, unaware that in the rush to get it working you haven’t
considered overall software quality or long-term maintainability. When informed that the product
must be rebuilt so that high levels of quality can be maintained, stakeholders cry foul and demand
that “a few fixes” be applied to make the prototype a working product. Too often, software
development management relents.

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

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Although problems can occur, prototyping can be an effective paradigm for software engineering.
The key is to define the rules of the game at the beginning; that is, all stakeholders should agree
that the prototype is built to serve as a mechanism for defining requirements. It is then discarded
(at least in part), and the actual software is engineered with an eye toward quality

The Spiral Model

Fig 2.5: A typical spiral model

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

The spiral model is an evolutionary software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the waterfall model. It provides the
potential for rapid development of increasingly more complete versions of the software. Boehm
describes the model in the following manner:

Using the spiral model, software is developed in a series of evolutionary releases. During early
iterations, the release might be a model or prototype. During later iterations, increasingly more
complete versions of the engineered system are produced

A spiral model is divided into a set of framework activities defined by the software engineering
team. Each of the framework activities represent one segment of the spiral path

The first circuit around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop a prototype and then progressively
more sophisticated versions of the software. Each pass through the planning region results in
adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from
the customer after delivery. In addition, the project manager adjusts the planned number of
iterations required to complete the software.

Unlike other process models that end when software is delivered, the spiral model can be adapted
to apply throughout the life of the computer software. Therefore, the first circuit around the spiral
might represent a “concept development project” that starts at the core of the spiral and continues
for multiple iterations until concept development is complete. If the concept is to be developed
into an actual product, the process proceeds outward on the spiral and a “new product development
project” commences. The new product will evolve through a number of iterations around the spiral

The spiral model is a realistic approach to the development of large-scale systems and software.
Because software evolves as the process progresses, the developer and customer better understand
and react to risks at each evolutionary level. The spiral model uses prototyping as a risk reduction
mechanism but, more important, enables you to apply the prototyping approach at any stage in the
evolution of the product

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

2.4 SPECIALIZED PROCESS MODELS

Component-Based Development Commercial off-the-shelf (COTS) software components,

developed by vendors who offer them as products, provide targeted functionality with well-defined
interfaces that enable the component to be integrated into the software that is to be built. The
component-based development model incorporates many of the characteristics of the spiral model.
It is evolutionary in nature, demanding an iterative approach to the creation of software. However,
the component-based development model constructs applications from prepackaged software
components.

Modeling and construction activities begin with the identification of candidate components. These
components can be designed as either conventional software modules or object-oriented classes or
packages of classes. Regardless of the technology that is used to create the components, the
component-based development model incorporates the following steps (implemented using an
evolutionary approach):

1. Available component-based products are researched and evaluated for the application domain
in question.

2. Component integration issues are considered.

3. A software architecture is designed to accommodate the components.

4. Components are integrated into the architecture.

5. Comprehensive testing is conducted to ensure proper functionality.

The component-based development model leads to software reuse, and reusability provides
software engineers with a number of measurable benefits. Your software engineering team can
achieve a reduction in development cycle time as well as a reduction in project cost if component
reuse becomes part of your culture. Component based development

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

The formal methods model

Formal methods model encompasses a set of activities that leads to formal mathematical
specification of computer software. Formal methods enable you to specify, develop, and verify a
computer-based system by applying a rigorous, mathematical notation. A variation on this
approach, called cleanroom software engineering, is currently applied by some software
development organizations.

When formal methods are used during development, they provide a mechanism for eliminating
many of the problems that are difficult to overcome using other software engineering paradigms.
Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily—not
through ad hoc review, but through the application of mathematical analysis. When formal
methods are used during design, they serve as a basis for program verification and therefore enable
you to discover and correct errors that might otherwise go undetected. Although not a mainstream
approach, the formal methods model offers the promise of defect-free software. Yet, concern about
its applicability in a business environment has been voiced:

The development of formal models is currently quite time consuming and expensive.

• Because few software developers have the necessary background to apply formal methods,
extensive training is required.

• It is difficult to use the models as a communication mechanism for technically unsophisticated

customers.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

Aspect-Oriented Software Development

Regardless of the software process that is chosen, the builders of complex software invariably
implement a set of localized features, functions, and information content. These localized software
characteristics are modeled as components (e.g., object oriented classes) and then constructed
within the context of a system architecture. As modern computer-based systems become more
sophisticated (and complex), certain concerns—customer required properties or areas of technical
interest—span the entire architecture. Some concerns are high-level properties of a system (e.g.,
security, fault tolerance). Other concerns affect functions (e.g., the application of business rules),
while others are systemic (e.g., task synchronization or memory management). When concerns cut
across multiple system functions, features, and information, they are often referred to as
crosscutting concerns. Aspectual requirements define those crosscutting concerns that have an
impact across the software architecture. Aspect-oriented software development (AOSD), often
referred to as aspect-oriented programming (AOP), is a relatively new software engineering
paradigm that provides a process and methodological approach for defining, specifying, designing,
and constructing aspects—“mechanisms beyond subroutines and inheritance for localizing the
expression of a crosscutting concern”.

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1

 RV Institute of Technology and Management®

SOFTWARE ENGINEERING&PROJECTMANAGEMENT (BCS501) 1