SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

MODULE – 1
SYLLABUS
Software and Software Engineering: The nature of Software, The unique nature of
WebApps, Software Engineering, The software Process, The software Engineering
practice, The software myths, How it all starts

Textbook 1: Chapter 1: 1.1 to 1.7

Process Models: A generic process model, Process assessment and improvement,

Prescriptive process models, Waterfall model, Incremental process models, Evolutionary
process models, Concurrent models, Specialized process models.

Textbook 1: Chapter 2: 2.1 to 2.4

SOFTWARE AND SOFTWARE ENGINEERING

SESSION - 1

1. The Nature of Software

Computer software continues to be the single most important technology on the

world stage. 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.

● 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 delivers the most important product of our time—information. The

role of computer software has undergone significant change over the last half-
century.

1.1 Defining Software:

A textbook description of software might take the following form:

1
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

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.

Characteristics of Software that makes it different from Hardware:

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

sense.

In both our focus is high quality. Both activities are dependent on people, but
the relationship between people and work accomplished 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.”

Hardware exhibits relatively high failure rates early in its life (design or
manufacturing defects); defects are corrected and the failure rate drops to a
steady-state level 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.

Failure Curve (bathtub curve) for hardware

Software is not susceptible to environmental maladies like hardware.

Undiscovered defects will cause high failure rates early in the life of a program.

2
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

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!

Failure curves for software

During its life, software will undergo change. As changes are made, errors will
be introduced, causing the failure rate curve to spike as shown in the “actual
curve”. Slowly the minimum failure rate level begins to rise—the software is
deteriorating due to change.

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

software continues to be custom built.

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. A software component should be designed and
implemented so that it can be reused in many different programs. Modern
reusable components encapsulate both data and the processing that is applied to
the data, enabling the software engineer to create new applications from
reusable parts.

1.2 Software Application Domains:

Seven broad categories of computer software present continuing challenges for

software engineers.

3
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

● 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,4 information structures. Other
systems applications (e.g Operating system components, drivers, networking
software, telecommunications processors) process largely indeterminate data.

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

● Engineering/scientific software -- 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.

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

● 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 etc)

● Web Applications -- his network-centric software category spans a wide

array of 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

● Artificial Intelligence software -- makes use of nonnumerical algorithms to

solve complex problems that are not amenable to computation or
straightforward analysis. Applications within this area include robotics, expert
systems, pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing.

1.3 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
state of- the-art software—just released to individuals, industry, and
government. But other programs are older, in some cases much older.

4
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

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

focus of continuous attention and concern since the 1960s.

As time passes, legacy systems often evolve for one or more of the following
reasons:

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

Questions

1 Explain how different is Software from a Hardware based on its

characteristics.
2 Explain the various Software Application Domains.
3 Mention few points on Legacy Software.

5
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

SESSION - 2

2. The unique nature of WebApps

In the early days of the World Wide Web, websites were just a set of linked
hypertext files which presented information using text and limited graphics. The
augmentation of HTML by development tools like Java, XML enabled web
engineers to provide computing capability along with informational content.

Web-based systems and applications (WebApps) are sophisticated tools that not
only present stand-alone information but also integrate databases and business
applications.

Web-based systems and applications “involve a mixture between print

publishing and software development, between marketing and computing,
between internal communications and external relations, and between art and
technology.”

The following are the common attributes for WebApps:

● Network intensiveness: A WebApp resides on a network (Internet or

Intranet) and must serve the needs of a diverse community of clients.

● Concurrency: A large number of users may access the WebApp at one time.

● Unpredictable load. The number of users of the WebApp may vary by orders
of magnitude from day to day.

● Performance: If a WebApp user must wait too long, he or she may decide to
go elsewhere.
● Availability: Although the expectation of 100 percent availability is
unreasonable, users of popular WebApps often demand access on a 24/7/365
basis.

● Data driven: The primary function of many WebApps is to use hypermedia

to present text, graphics, audio, and video content to the end user

● Content sensitive: The quality and aesthetic nature of content remains an

important determinant of the quality of a WebApp.

● Continuous evolution: Unlike conventional application software that evolves

over a series of planned, chronologically spaced releases, Web applications
evolve continuously.

6
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

● Immediacy: WebApps often exhibit a time-to-market that can be a matter of

a few days or weeks.

● Security: Because WebApps are available via network access sensitive

content must be protected and secure modes of data transmission must be
provided.

● Aesthetics: An undeniable part of the appeal of a WebApp is its look and

feel.

3. Software Engineering

In order to build software that is ready to meet the challenges of the twenty-first
century, you must recognize a few simple realities:

➔ It follows that a concerted effort should be made to understand the problem

before a software solution is developed.
➔ It follows that design becomes a pivotal activity.
➔ It follows that software should exhibit high quality.
➔ It follows that software should be maintainable.

These simple realities lead to one conclusion: software in all of its forms and
across all of its application domains should be engineered.

The IEEE has developed a comprehensive definition for Software Engineering,

where it states:
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).

Software engineering is a layered technology

● Any engineering approach (including software engineering) must rest on an

organizational commitment to quality. The bedrock that supports software
engineering is a quality focus.

● The foundation for software engineering is the process layer. The software
engineering process is the glue that holds the technology layers together and

7
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

enables rational and timely development of computer software. Process defines

a framework

● Software engineering methods provide the technical how-to’s for building

software. Methods encompass a broad array of tasks that include
communication, requirements analysis, design modeling, program construction,
testing, and support.

● Software engineering tools provide automated or semi automated support for

the process and the methods.

4. The Software Process

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.

A process is not a rigid prescription for how to build computer software. Rather,
it is an adaptable approach that enables the people doing the work (the software
team) to pick and choose the appropriate set of work actions and tasks. The
intent is always to deliver software in a timely manner and with sufficient
quality to satisfy those who have sponsored its creation and those who will use
it.

8
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

A process framework establishes the foundation for a complete software

engineering process by identifying a small number of framework activities that
are applicable to all software projects, regardless of their size or complexity.

A generic process framework for software engineering encompasses five

activities:

● Communication: Before any technical work can commence, it is critically

important to communicate and collaborate with the customer, to understand
objectives of the project and to gather requirements.

● Planning: A software project is a complicated journey, and the planning

activity creates a “map” that helps guide the team as it makes the journey. The
map—called a software project plan—defines the software engineering work by
describing the technical tasks to be conducted, the risks that are likely, the
resources that will be required, the work products to be produced, and a work
schedule.

● Modeling: Creating models to better understand software requirements and

the design that will achieve those requirements.

● Construction: This activity combines code generation and the testing that is
required to uncover errors in the code.

● Deployment: The software is delivered to the customer who evaluates the

delivered product and provides feedback based on the evaluation.

These five generic framework activities can be used during the development of
small, simple programs, the creation of large Web applications, and for the
engineering of large, complex computer-based systems.

Questions

1 Define WebApps.
2 Summarize on the common attributes for WebApps.
3 Define software engineering.
4 Explain the layers in software engineering.
5 Define Software Process.
6 Mention the activities in a generic process framework.

9
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

SESSION - 3

5. Software Engineering Practice

The Essence of Practice:
The essence of problem solving is essentially the essence of software
engineering practice. Here we try to answer some of the questions under
different phases of problem solving.
● Understand the problem (communication and analysis).
○ Who has a stake in the solution to the problem?
○ What are the unknowns?
○ Can the problem be compartmentalized?
○ Can the problem be represented graphically?

● Plan a solution (modeling and software design).

○ Have you seen similar problems before?
○ Has a similar problem been solved?
○ Can subproblems be defined?
○ Can subproblems be defined?

● Carry out the plan (code generation).

○ Does the solution conform to the plan?
○ Is each component part of the solution provably correct?

● Examine the result for accuracy (testing and quality assurance).

○ Is each component part of the solution provably correct?
○ Does the solution produce results that conform to the data, functions, and
features that are required?

General Principles of Software Engineering:

The word principle is “an important underlying law or assumption required in a

system of thought.” David Hooker has proposed seven principles that focus on
software engineering practice as a whole.

1. The First Principle: The Reason It All Exists

A software system exists for one reason: to provide value to its users. All
decisions should be made with this in mind.

2. The Second Principle: KISS (Keep It Simple, Stupid!)

All design should be as simple as possible, but no simpler. This facilitates
having a more easily understood and easily maintained system.

10
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

3. The Third Principle: Maintain the Vision

A clear vision is essential to the success of a software project. Without one, a
project almost unfailingly ends up being “of two [or more] minds” about itself.
4. The Fourth Principle: What You Produce, Others Will Consume
always specify, design, and implement knowing someone else will have to
understand what you are doing. The audience for any product of software
development is potentially large.
5. The Fifth Principle: Be Open to the Future
Never design yourself into a corner. Always ask “what if,” and prepare for all
possible answers by creating systems that solve the general problem, not just the
specific one.
6. The Sixth Principle: Plan Ahead for Reuse
Planning ahead for reuse reduces the cost and increases the value of both the
reusable components and the systems into which they are incorporated.
7. The Seventh principle: Think!
Placing clear, complete thought before action almost always produces better
results. When you think about something, you are more likely to do it right. You
also gain knowledge about how to do it right again.

6. Software Myths
Software myths are erroneous beliefs about software and the process that is used
to build it. We categorize myths from three different perspectives.
Management myths:
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 is it used? Are software
practitioners aware of its existence? Does it reflect modern software engineering
practice? Is it complete? Is it adaptable? Is it streamlined to improve time-to-
delivery while still maintaining a focus on quality? In many cases, the answer to
all of these questions is “no.”
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 are 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.

11
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

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 out-sources
software projects.

Customer myths.
Myth: A general statement of objectives is sufficient to begin writing
programs—we can fill in the details later.
Reality: Although a comprehensive and stable statement of requirements is not
always possible, an ambiguous “statement of objectives” is a recipe for disaster.
Myth: Software 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 requirements changes are
requested early (before design or code has been started), the cost impact is
relatively small. However, as time passes, the cost impact grows rapidly.

Practitioner’s myths:
Myth: 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.
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 technical review.
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.
Myth: Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about
creating a quality product. Better quality leads to reduced rework.

12
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

7. How it all Starts

Every software project is precipitated by some business need—the need to
correct a defect in an existing application; the need to adapt a “legacy system”
to a changing business environment; the need to extend the functions and
features of an existing application; or the need to create a new product, service,
or system.
At the beginning of a software project, the business need is often expressed
informally as part of a simple conversation. The conversation presented in the
sidebar is typical.

Questions

1 Explain the general principles of Software Engineering.

2 Explain Management Myth with an example.
3 Explain Customer Myth with an example.
4 Explain Practitioners Myth with an example.

13
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

SESSION - 4
PROCESS MODELS
8. Generic Process Model:
● A process was defined as a collection of work activities, actions, and tasks
that are performed when some work product is to be created.
● Each of these activities, actions, and tasks reside within a framework or model
that defines their relationship with the process and with one another.
● A generic process framework for software engineering defines five
framework activities — communication, planning, modeling, construction,
and deployment.
● Each framework activity is populated by a set of software engineering actions.
● Each software engineering action is defined by a task set that identifies the
work tasks that are to be completed, the work products that will be produced,
the quality assurance points that will be required, and the milestones that will be
used to indicate progress.
● One important aspect of the software process called 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.

14
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

Defining a Framework Activity:

To properly execute any one of these activities as part of the software process, a
key question that the software team needs to ask is:

What actions are appropriate for a framework activity, given the nature of the
problem to be solved, the characteristics of the people doing the work, and the
stakeholders who are sponsoring the project?

For a small software project requested by one person (at a remote location) with
simple, straightforward requirements, the communication activity might
encompass little more than a phone call with the appropriate stakeholder. The
work tasks that this action encompasses are:

1. Make contact with stakeholder via telephone.

2. Discuss requirements and take notes
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.

If the project was considerably more complex with many stakeholders, each
with a different set of requirements, the communication activity might have six
distinct actions: inception, elicitation, elaboration, negotiation, specification,
and validation.

Identifying a Task Set

Each software engineering action can be represented by a number of different
task sets—each a collection of software engineering work tasks, related work
products, quality assurance points, and project milestones. You should choose a
task set that best accommodates the needs of the project and the characteristics
of your team.

Process Patterns
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., TechnicalReviews).

15
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

Forces. The environment in which the pattern is encountered and the issues that
make the problem visible and may affect its solution.

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 that are relevant to the
stage (framework activity).
An example of a stage pattern might be EstablishingCommunication. This
pattern would incorporate the task pattern RequirementsGathering 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., RequirementsGathering 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
(3) the project scope, basic business requirements, and project constraints are
known.

Problem. The specific problem to be solved by the pattern.

Solution. Describes how to implement the pattern successfully. This section

describes how the initial state of the process (that exists before the pattern is
implemented) is modified as a consequence of the initiation of the pattern. It
also describes how software engineering information or project information that
is available before the initiation of the pattern is transformed as a consequence
of the successful execution of the pattern.

16
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

Resulting Context. Describes the conditions that will result once the pattern has
been successfully implemented. Upon completion of the pattern:

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

(2) What is the exit state for the process?
(3) What software engineering information or project information has been
developed?

Related Patterns. Provide a list of all process patterns that are directly related
to this one. This may be represented as a hierarchy or in some other
diagrammatic form. For example, the stage pattern Communication
encompasses the task patterns: ProjectTeam, CollaborativeGuidelines,
ScopeIsolation, RequirementsGathering, ConstraintDescription, and
ScenarioCreation.

Known Uses and Examples. Indicate the specific instances in which the pattern
is applicable. For example, Communication is mandatory at the beginning of
every software project, is recommended throughout the software project, and is
mandatory once the deployment activity is under way.

9. Process Assessment and Improvement

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

delivered on time, that it will meet the customer’s needs, or that it will exhibit
the technical characteristics that will lead to long-term quality characteristics.

Process patterns must be coupled with solid software engineering practice. In

addition, the process itself can be assessed to ensure that it meets a set of basic
process criteria that have been shown to be essential for a successful software
engineering

A number of different approaches to software process assessment 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.

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

17
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

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.

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.

Questions

1 Name the 5 activities in a generic process framework.

2 Define process pattern.
3 Explain the template used in presenting a process pattern.
4 Name some of the assessment approaches used in software process.

18
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

SESSION - 5

10. Prescriptive Process Models

Prescriptive process models were originally proposed to bring order to the chaos
of software development. Software engineering work and the product that it
produces remain on “the edge of chaos.”

All software process models can accommodate the generic framework activities,
but each applies a different emphasis to these activities and defines a process
low that invokes each framework activity in a different manner.

The Waterfall Model

The original waterfall model proposed by Winston Royce made provision for
“feedback loops,” the vast majority of organizations that apply this process
model treat it as if it were strictly linear.

● The waterfall model is the oldest paradigm for software engineering. the
problems that are sometimes encountered when the waterfall model is applied
are:

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

4. The linear nature of the classic life cycle leads to “blocking states” in which
some project team members must wait for other members of the team to
complete dependent tasks. In fact, the time spent waiting can exceed the time
spent on productive work.

●The waterfall model is often inappropriate today, as software work is fast-

paced and subject to a never-ending stream of changes.

19
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

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

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

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.

20
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

● 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 remain undelivered.

● The core product is used by the customer (or undergoes detailed evaluation).

● As a result, a plan is developed for the next increment. The plan addresses the
modification of the core product to better meet the needs of the customer and
the delivery of additional features and functionality.

● This process is repeated following the delivery of each increment, until the
complete product is produced.

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

○ 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

21
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

document production capabilities in the second increment; spelling and

grammar checking in the third increment; and advanced page layout capability
in the fourth increment.

● Incremental development is particularly useful when staffing is unavailable

for a complete implementation by the business deadline that has been
established for the project.

Questions

1 Explain about waterfall model.

2 Explain the process in V model.
3 Explain about Incremental process model with an example.

22
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

SESSION - 6

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.

There are two common evolutionary process models.

Prototyping
● 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.
● The prototyping paradigm assists you and other stakeholders to better
understand what is to be built when requirements are fuzzy.

➔ The prototyping paradigm begins with communication.

◆ You meet with other stakeholders to define the overall objectives for the
software, identify whatever requirements are known, and outline areas
where further definition is mandatory.

➔ A prototyping iteration is planned quickly, and modeling (in the form of a

“quick design”) occurs.
◆ A quick design focuses on a representation of those aspects of the
software that will be visible to end users.

➔ The quick design leads to the construction of a prototype.

➔ The prototype is deployed and evaluated by stakeholders, who provide

feedback that is used to further refine requirements.

➔ Iteration occurs as the prototype is tuned to satisfy the needs of various

stakeholders, while at the same time enabling you to better understand what
needs to be done.

23
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

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

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

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.

24
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

The Spiral Model

● Originally proposed by Barry Boehm, 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.
● 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.
○ As this evolutionary process begins, the software team performs activities
that are implied by a circuit around the spiral in a clockwise direction,
beginning at the center.
○ Risk is considered as each revolution is made.
○ Anchor point milestones—a combination of work products and conditions
that are attained along the path of the spiral—are noted for each
evolutionary pass.

25
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

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

● 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
importantly, enables you to apply the prototyping approach at any stage in the
evolution of the product.

● It maintains the systematic stepwise approach suggested by the classic life

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

Questions

1 When will we use an evolutionary process model ?

2 Name the two common evolutionary process models.
3 Explain prototyping.
4 Explain spiral model.

26
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

SESSION - 7

Concurrent Models
The concurrent development model, sometimes called concurrent engineering,
allows a software team to represent iterative and concurrent elements of any of
the process models described in this chapter.

The figure below provides a schematic representation of one software

engineering activity within the modeling activity using a concurrent modeling
approach.

The activity—modeling—may be in any one of the states noted at any given

time. For example, early in a project the communication activity (not shown in
the figure) has completed its first iteration and exists in the awaiting changes
state. The modelling activity (which existed in the inactive state while initial
communication was completed, now makes a transition into the under
development state. If, however, the customer indicates that changes in
requirements must be made, the modeling activity moves from the under
development state into the awaiting changes state.

Concurrent modeling defines a series of events that will trigger transitions from
state to state for each of the software engineering activities, actions, or tasks.

27
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

11. Specialized Process Models

Specialized process models take on many of the characteristics of one or more

of the traditional models presented in the preceding sections. However, these
models tend to be applied when a specialized or narrowly defined software
engineering approach is chosen.

Component-Based Development
The component-based development model incorporates many of the
characteristics of the spiral model. It is evolutionary in nature, demanding an
iterative approach to the creation of software. However, the component-based
development model constructs applications from prepackaged software
components.

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 Formal Methods Model

The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software. Formal methods enable you to
specify, develop, and verify a computer-based system by applying a rigorous,
mathematical notation. A variation on this approach, called 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.

28
 SOFTWARE ENGINEERING AND PROJECT MANAGEMENT [21CS61]

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.

Aspect-Oriented Software Development

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.

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.

Questions

1 Explain modeling activity that happens in a concurrent model.

2 Define concurrent model.
3 Explain component based model.
4 Explain formal method model.
5 Explain aspect oriented software development.

********

29