UNIT-I

Chapter-1
INTRODUCTION TO SOFTWARE ENGINEERING

Objective of the Course:

(To Understand the concept of a software life cycle and the role of process maturity models and
apply key elements and common methods for elicitation and analysis to produce a set of software
requirements. To distinguish between the different types and levels of testing (unit,integration,
systems, and acceptance).

Unit-I

Introduction to Software Engineering : The evolving role of software, Changing Nature of

Software,Software myths.A Generic view of process : Software engineering- A layered technology,
a process framework, The Capability Maturity Model Integration (CMMI), Process patterns,
process assessment,personal and team process models.
Process models : The waterfall model, Incremental process models, Evolutionary process models,
The Unified process.]

Unit-1 Objective:
 To introduce software engineering and to explain its importance
 To set out the answers to key questions about software engineering
 To introduce ethical and professional issues and to explain why they are of concern to
software engineers

1.1 What is Software?

In 1970, less than 1 percent of the public could have intelligently described what "computer
software" meant.

We can difine the Software in many ways.

1. Software is instructions (computer programs) that when executed provide desired function
and performance
2. Software is data structures that enable the programs to adequately manipulate information.
3. Software is documents that describe the operation and use of the programs.
4. Software is a set of items or objects that form a “configuration” that includes
 programs
 documents
 data ...

5. Software is the collection of computer programs, procedures, Rules and associate with
documentation and data.

1.2 The evolving role of software:

Software can be considered in a dual role (Product and a vehicle for delivering a Product)
1. Software is a product
 Delivers computing potential
  Produces, manages, acquires, modifies, displays, or transmits information

2. Software is a vehicle for delivering a product

 Supports or directly provides system functionality
 Controls other programs (e.g., an operating system)
 Effects communications (e.g., networking software)
 Helps build other software (e.g., software tools)

Here are the some more definitions in popular books published during the 1970s and 1980s
provide useful historical insight into the changing perception of computers and software and their
impact on
our culture.

 Osborne [OSB79] characterized a "new industrial revolution."

 Toffler [TOF80] called the advent of microelectronics part of "the third wave of change" in
human history.
 Naisbitt [NAI82] predicted a transformation from an industrial society to an "information
society." Feigenbaum and McCorduck [FEI83] suggested that information and knowledge
(controlled by computers) would be the focal point for power in the twenty-first century.
 Stoll [STO89] argued that the "electronic community" created by networks and software
was the key to knowledge interchange throughout the world.

1.3 Changing nature of Software:

The following categories of computer software present the challenges for the Software.
System Software:
System Software is a collection of programs written to service other programs.
Ex:(Compilers, Editors, File management utilities, Operating system components, Drivers,
Telecommunications, Processors process largely indeterminate data.)

Application Software:
Application Software consists of standalone programs that solve a specific business need.
Ex:(Point on sales transaction processing, Billing system in shopping mals.)

Engineering and Scientific Software:

This is the Software using different algorithms for different science and applications.
Ex:(System Simulation, Computer Aided Design.)

Embedded Software:
Embedded Software resides in read only memory and is used to control products and
systems for the consumer and industrial markets. It has very limited and mysterious
functions and control capability.

Product-line Software:
It is designed to provide a specific facility for use by many different customers.
Ex:(Inventory control products, word processing, spread sheets, graphics, multimedia etc.,)

Web based Software:

The Web pages retrieved by a browser are software that includes executable instructions.
Ex:(Html, Javascript, Perl etc.,)

Artificial Intelligence(AI) Software:

 AI Software makes use of non numerical algorithms to solve complex problems.
Ex: (Expert Systems, Pattern Recognition, Games etc.,)

Business Software:
Business information processing is the largest single software application area. Discrete
"systems" have evolved into management information system (MIS) software that accesses
one or more large databases containing business information. Applications in this area
restructure existing data in a way that facilitates business operations or management
decision making.
Ex:(payroll, accounts receivable/payable, inventory)
1.4 Software Myths:

What are Myths?

"Myths are stories told by people about people: where they come from, how they handle
major disasters, how they cope with what they must and how everything will end. If that isn't
eveything what else is there?"
(or)
Myth is a Strong belief which is not true.
Today, most knowledgeable professionals recognize myths for what they are— misleading
attitudes that have caused serious problems for managers and technical people alike. However, old
attitudes and habits are difficult to modify, and remnants of software myths are still believed.

Software Myths are of three types:

 Mangement Myths
 Customer Myths
 Practitioner's Myths

Management myths:
Managers with software responsibility, like managers in most disciplines, are often under
pressure to maintain budgets, keep schedules from slipping, and improve quality.

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
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: My people have state-of-the-art software development tools, after all, we buy them the
newest computers.
Reality: It takes much more than the latest model mainframe, workstation, or PC to do high-quality
software development. Computer-aided software engineering (CASE) tools are more
important than hardware for achieving good quality and productivity, yet the majority of
software developers still do not use them effectively.

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. In the words of. At
first, this statement may seem counterintuitive. However, as new people are added, people
who were working must spend time educating the newcomers, thereby reducing the amount
of time spent on productive development effort. People can be added but only in a planned
and well-coordinated manner.
Myth: If I decide to outsource3 the software project to a third party, I can just relax
and let that firm build it.
Reality: If an organization does not understand how to manage and control software
projects internally, it will invariably struggle when it outsources software projects.

Customer Myths:
Customers may be defined as follows:
 An outside company that has requested software under contract.
 A person next to your desk.
 A technical group.
 A marketing or sales group.

Customer Myths lead to false expectations (by the customer) and ultimately, dissatisfaction with the
developer.

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: It is true that software requirements change, but the impact of change varies with the time
at which it is introduced. The 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. Resources have been committed and a design framework has been established.
Change can cause upheaval that requires additional resources and major design modification, that
is, additional cost. Changes in function, performance, interface, or other characteristics during
implementation (code and test) have a severe impact on cost. Change, when requested after
software is in production, can be over an order of magnitude more expensive than the same change
requested earlier.

Practitioner's Myths:
A Practitioner may be planning group, Developmet group, Verification group, Support group,
Marketing/Sales.

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 formal technical review. Software reviews are a "quality filter" that have
been found to be more effective than testing for finding certain classes of software defects.

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. Documentation provides a foundation for successful engineering and, more important,
guidance for software support.

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 quality. Better
quality leads to reduced rework. And reduced rework results in faster delivery times.

Chapter-2
A GENERIC VIEW OF PROCESS

Introduction: Before going to know about Software Engineering it is important to examine the
characteristics of software that make it different from other things that human beings build.

Software is a logical rather than a physical system element.

Let us know the difference between hardware and software, when hardware is built, the human
creative process (analysis, design, construction, testing) is ultimately translated into a physical form.

For example if we build a new computer, our initial sketches, formal design drawings, and
breadboarded prototype evolve into a physical product (chips, circuit boards, power supplies, etc.).

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

Some similarities exist between Software development and hardware manufacture.
 Two activities are fundamentally different.
 In both activities, high quality is achieved through good design.
 But the manufacturing phase for hardware can introduce quality problems and that are
easily corrected for software.
 Both activities are dependent on people, but the relationship between people applied
and distribution of work among them is entirely different.
 Both activities require the construction of a "product" but the approaches are different.
 The software projects cannot be managed as easily as manufacturing projects.

2. Software doesn't "wear out".

 Hardware exhibits relatively high failure rates in its life, defects are corrected and the
failure rates drop 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.
 Simply this can be called as Hardware wear out.
 Software is not susceptible to the environmental maladies that cause hardware to
wear out.
 When the Software doesn't meet the needs of the users, then only we can say that
Software is failed.

3. Althogh the industry is moving toward component-based assembly, most software continues
to be custome 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.
 In the 1960s, we built scientific subroutine libraries that were reusable in a broad array
of engineering and scientific applications. These subroutine libraries reused well-defined
algorithms in an effective manner but had a limited domain of application.
 Today, we have extended our view of reuse to encompass not only algorithms but also
data structure. Modern reusable components encapsulate both data and the processing
applied to the data, enabling the software engineer to create new applications from
reusable parts.
 For example, today's graphical user interfaces are built using reusable components that
enable the creation of graphics windows, pull-down menus, and a wide variety of
interaction mechanisms.
 The data structure and processing detail required to build the interface are contained
with a library of reusable components for interface construction.

2.1 What is Software Engineering?

There are many definitions for Software Engineering, a definition proposed by Fritz Bauer
is:
"Software Engineering is is the establishment and use of sound engineering principles in order to
obtain economical software that is reliable and work efficiently on real machines."

The IEEE definition for Software Engineering is:

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).
(or)
Software Engineering is a systematic approach to development, operation, maintenance and
retirement of software.

Goal of Software Engineering is:

The software produce high quality software at low cost

Software Engineering: A Layered Technology

Software engineering is a layered technology, any engineering approach (including software
engineering) must rest on an organizational commitment to quality. Total quality management and
similar philosophies foster a continuous process improvement culture, and this culture ultimately
leads to the development of increasingly more mature approaches to software engineering.
Process: Provides the glue that holds the layers together; enables rational and timely development;
provides a framework for effective delivery of technology; forms the basis for management;
provides the context for technical methods, work products, milestones, quality measures, and
change management.
Methods: Provide the technical "how to" for building software; rely on a set of basic principles;
encompass a broad array of tasks; include modeling activities
Tools: Provide automated or semi-automated support for the process and methods (i.e., CASE
tools)

2.2 A Process Framework:

A common process framework is established by defining a small number of framework activities

that are applicable to all software projects, regardless of their size or complexity. Umbralla activities
are independent of any one framework activity and occur through out the process.

A number of task sets—each a collection of software engineering work tasks, project milestones,
work products, and quality assurance points—enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the project team.
Finally, umbrella activities—such as software quality assurance, software configuration
management, and measurement—overlay the process model.

Umbrella activities are independent of any one framework activity and occur throughout
the process.

Framework Activities:
 A common process framework is established by defining a small number of framework
activities that are applicable to all software projects, regardless of their size or complexity.
 A number of task sets—each a collection of software engineering work tasks, project
milestones, work products, and quality assurance points—enable the framework activities to
be adapted to the characteristics of the software project and the requirements of the project
team.

Umbrella Activities:
 Umbrella activities such as software quality assurance, software configuration management,
and measurement
 Umbrella activities are independent of any one framework activity and occur throughout
the process.
 There has been a significant emphasis on "process maturity".
 Software requirements management
 Software project planning
 Software project tracking and oversight
 Software quality assurance
 Software configuration management
 Software subcontract management
 Formal technical reviews
 Risk management
 Measurement – process, project, product
 Reusability management (component reuse)
  Work product preparation and production

2.3 The Capability Maturity Model Integration(CMMI):

Capability Maturity Model Integration (CMMI) is a process improvement approach that helps
organizations improve their performance. CMMI can be used to guide process improvement across
a project, a division, or an entire organization.

CMMI in software engineering and organizational development is a process improvement approach

that provides organization with the essential elements for effective process improvement. CMMI is
registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

According to the Software Engineering Institute (SEI, 2008), CMMI helps "integrate traditionally
separate organizational functions, set process improvement goals and priorities, provide guidance
for quality processes, and provide a point of reference for appraising current processes."

CMMI currently addresses three areas of interest:

  Product and service development — CMMI for Development (CMMI-DEV),
 Service establishment, management, and delivery — CMMI for Services (CMMI-SVC), and
 Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).

Level 1: Initial. The software process is characterized as ad hoc and occasionally even chaotic.
Few processes are defined, and success depends on individual effort.

Level 2: Manageable. Basic project management processes are established to track cost, schedule,
and functionality. The necessary process discipline is in place to repeat earlier successes on projects
with similar applications.

Level 3: Defined. The software process for both management and engineering activities is
documented, standardized, and integrated into an organizationwide software process. All projects
use a documented and approved version of the organization's process for developing and supporting
software. This level includes all characteristics defined for level 2.

Level 4: Quantitatively Managed. Detailed measures of the software process and product quality
are collected. Both the software process and products are quantitatively understood and controlled
using detailed measures. This level includes all characteristics defined for level 3.

Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from

the process and from testing innovative ideas and technologies. This level includes all
characteristics defined for level 4.

2.4 Process Patterns:

A project's process specification defines the tasks the project should perform, and the order in which
they should be done. Process patterns define a set of activities, actions, work tasks, work products
and related behaviours that must be done to complete the project.
 A template is used to define a pattern

Typical Process Patterns are:

 Customer communication
 Planning (Requirements gathering)
 Modeling
 Construction
 Deployment
Communication
Involves communication among the customer and other stake holders; encompasses requirements
gathering
Planning
Establishes a plan for software engineering work; addresses technical tasks, resources, work
products, and work schedule
Modeling (Analyze, Design)
Encompasses the creation of models to better understand the requirements and the design
Construction (Code, Test)
Combines code generation and testing to uncover errors
Deployment
Involves delivery of software to the customer for evaluation and feedback
2.5 Process Assessment:

Software
Process

Is examined
by Identifies
Identifies modification SPA Capabilities and
To SPA Software
Process risk of SP
Assessment

Leads Leads to
to
Software Capability
Process Determinatio
Improvement n
Motivates

2.6 Personal and Team Process Models:

Personal Software Process (PSP):

Planning, high level design, high level design review, development, postmortem.

The Personal Software Process (PSP) is a structured software development process that is
intended to help software engineers understand and improve their performance, by using a
"disciplined, data-driven procedure". The PSP was created by Watts Humphrey to apply the
underlying principles of the Software Engineering Institute's (SEI) Capability Maturity
Model (CMM) to the software development practices of a single developer. It claims to give
software engineers the process skills necessary to work on a Team Software Process (TSP) team.
"Personal Software Process" and "PSP" are registered service marks of the Carnegie Mellon
University.
PSP has been likened to applying Six Sigma toward Software development. Mukesh Jain led large
scale deployment of PSP/TSP in Microsoft India. Within 6 months, more than 2/3 of the projects
shipped were without any defects and 94% of the projects were delivered on time

The PSP helps software engineers to:

Improve their estimating and planning skills.
Make commitments they can keep.
Manage the quality of their projects.
Reduce the number of defects in their work.
The goal of the PSP is to help developers produce zero-defect, quality products on schedule. Low-
defect and zero defect products have become the reality for some developers and TSP teams,
Process:
The input to PSP is the requirements; requirements document is completed and delivered to the
engineer.
PSP0, PSP0.1 (Introduces process discipline and measurement) PSP0 has 3 phases: planning,
development (design, coding, test) and a post mortem. A baseline is established of current process
measuring: time spent on programming, faults injected/removed, size of a program. In a post
mortem, the engineer ensures all data for the projects has been properly recorded and analysed.
PSP0.1 advances the process by adding a coding standard, a size measurement and the development
of a personal process improvement plan (PIP). In the PIP, the engineer records ideas for improving
his own process.
PSP1, PSP1.1 (Introduces estimating and planning) Based upon the baseline data collected in
PSP0 and PSP0.1, the engineer estimates how large a new program will be and prepares a test
report (PSP1). Accumulated data from previous projects is used to estimate the total time. Each new
project will record the actual time spent. This information is used for task and schedule planning
and estimation (PSP1.1).
PSP2, PSP2.1 (Introduces quality management and design) PSP2 adds two new phases: design
review and code review. Defect prevention and removal are the focus at the PSP2. Engineers learn
to evaluate and improve their process by measuring how long tasks take and the number of defects
they inject and remove in each phase of development. Engineers construct and use checklists for
design and code reviews. PSP2.1 introduces design specification and analysis techniques

Team Software Process (TSP):

Build self-directed, managers, software process, improvement guidance, teaching.

The TSP is intended to improve the levels of quality and productivity of a team's software
development project, in order to help them better meet the cost and schedule commitments of
developing a software system.
The initial version of the TSP was developed and piloted by Watts Humphrey in the late 1990s and
the Technical Report for TSP sponsored by the U.S. Department of Defense was published in
November 2000. The book by Watts Humphrey, Introduction to the Team Software Process,
presents a view the TSP intended for use in academic settings, that focuses on the process of
building a software production team, establishing team goals, distributing team roles, and other
teamwork-related activities.

How TSP works?

 Before engineers can participate in the TSP, it is required that they have already learned
about the PSP, so that the TSP can work effectively. Training is also required for other team
members, the team lead, and management.
 The coach role focuses on supporting the team and the individuals on the team as the
process expert while being independent of direct project management responsibility.The
team leader role is different from the coach role in that, team leaders are responsible to
management for products and project outcomes while the coach is responsible for
developing individual and team performance.

Chapter-3
PROCESS MODELS

Objectives:
 To introduce software engineering and to explain its importance
  To set out the answers to key questions about software engineering
 To introduce ethical and professional issues and to explain why they are of concern to
software engineers

Introduction: A process model specifies a general process, usually as a set of stages in which a
project should be divided, the order in which the stages should be executed, any other constraints
and conditions on the execution of stages.

Selction of process model is based on:

 the nature of the project and application.
 the methods and tools to be used
 the controls and deliverables

All software development can be characterized as a problem solving loop in which four distinct
stages are encountered:
1. Status quo
2. Problem definition
3. Technical development
4. Solution integration

1. Status quo:
It represents the current state of affairs.
2. Problem definition
Identifies the specific problem to be solved and defines them.
3. Technical development
Solves the problem through the application of some technology.
4. Solution integration
It applies the solution and delivers the results.
Ex: documents, programs, data, new business function, new product.

3.1 Waterfall Model:

This waterfall model is also termed as linear sequential model. Linear ordering of activities has
some important consequences. First, to clearly identify the end of a phase and the beginning of the
next, some certification mechanism has to be employed at the end of each phase. This is usually
done by some verificatin and validation means that will ensure that output of a phase is consistent
with its input, and that the output of the phase is consistent with the overall requirements f the
system.
Waterfall model suggests a systematic, sequential approach to software development that begins at
the system level and progress through different phases like:

1. Analysis
2. Design
3. Coding
4. Testing
5. Support
 Analysi Support
Design Code Test
s

1. Software requirements analysis. The requirements gathering process is intensified and

focused specifically on software. To understand the nature of the program(s) to be built, the
software engineer ("analyst") must understand the information domain (described in Chapter
11) for the software, as well as required function, behavior, performance, and interface.
Requirements for both the system and the software are documented and reviewed with the
customer.
2. Design: Software design is actually a multistep process that focuses on four distinct
attributes of a program: data structure, software architecture, interface representations, and
procedural (algorithmic) detail. The design process translates requirements into a
representation of the software that can be assessed for quality before coding begins. Like
requirements, the design is documented and becomes part of the software configuration.

3. Coding: The design must be translated into a machine-readable form. The code generation
step performs this task. If design is performed in a detailed manner, code generation can be
accomplished mechanistically.

4. Testing: Once code has been generated, program testing begins. The testing process focuses
on the logical internals of the software, ensuring that all statements have been tested, and on
the functional externals; that is, conducting tests to uncover errors and ensure that defined
input will produce actual results that agree with required results.

5. Support: Software will undoubtedly undergo change after it is delivered to the customer
(a possible exception is embedded software). Change will occur because errors have been
encountered, because the software must be adapted to accommodate changes in its external
environment (e.g., a change required because of a new operating system or peripheral
device), or because the customer requires functional or performance enhancements.
Software support/maintenance reapplies each of the preceding phases to an existing program
rather than a new one.

The linear sequential model is the oldest and the most widely used paradigm for software
engineering. However, this model has some drawbacks.
Drawbacks:

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

3.2 Incremental Model:

The incremental model combines elements of the linear sequential model (applied repetitively)
with the iterative philosophy of prototyping.

Each linear sequence produces a deliverable “increment” of the software

For example,
 word-processing software developed using the incremental paradigm might deliver basic file
management, editing, and document production functions in the first increment.
 more sophisticated editing and document production capabilities in the second increment.
 spelling and grammar checking in the third increment.
 and advanced page layout capability in the fourth increment.
 It should be noted that the process flow for any increment can incorporate the prototyping
paradigm.

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 review).
 As a result of use and/or evaluation, 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.

3.3 Evaluationary process models:

Business and product requirements often change as development proceeds, Classic process models
are not designed to deliver a production system.

Due to their assumptions on:

 A complete system will be delivered after the linear sequence is completed.
 Customer knows what they want at the early stage.

The realty in a software productin process

 A lot of requirements changes during the productin course.
 A lot of iterative activities and work because of the evaluationary nature of software
production.

The several evaluation process models proposed are:

 The incremental model
 The spiral model
 The concurrent development model
 The component assembly model

3.4 Spiral Model:

The spiral model, originally proposed by Boehm , is an evolutionary software process model that
couples the iterative nature of prototyping with the controlled and systematic aspects of the linear
sequential model.
 It provides the potential for rapid development of incremental versions of the software.
Using the spiral model, software is developed in a series of incremental releases.
 During early iterations, the incremental release might be a paper model or prototype.
 During later iterations, increasingly more complete versions of the engineered system are
produced.
A spiral model is divided into a number of framework activities, also called task regions. Typically,
there are between three and six task regions. Below Figure depicts a spiral model that contains six
task regions:

 Customer communication—tasks required to establish effective communication

between developer and customer.
 Planning—tasks required to define resources, timelines, and other projectrelated
information.
 Risk analysis—tasks required to assess both technical and management
risks.
 Engineering—tasks required to build one or more representations of the
application.
 Construction and release—tasks required to construct, test, install, and
provide user support (e.g., documentation and training).
 Customer evaluation—tasks required to obtain customer feedback based
on evaluation of the software representations created during the engineering
stage and implemented during the installation stage.

 For small projects, the number of work tasks and their formality is low.
 For larger, more critical projects, each task region contains more work tasks that are defined
to achieve a higher level of formality.
 In all cases, the umbrella activities (e.g., software configuration management and software
quality assurance) are applied.
 As this evolutionary process begins, the software engineering team moves around the spiral
in a clockwise direction, beginning at the center.
 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 customer evaluation. In addition, the
project manager adjusts the planned number of iterations required to complete the software.
 Unlike classical process models that end when software is delivered, the spiral model can be
adapted to apply throughout the life of the computer software.
 An alternative view of the spiral model can be considered by examining the project entry
point axis, also shown in Figure.
 Each cube placed along the axis can be used to represent the starting point for different types
of projects.
 A “concept development project” starts at the core of the spiral and will continue (multiple
iterations occur along the spiral path that bounds the central shaded region) until concept
development is complete.
 If the concept is to be developed into an actual product, the process proceeds through the
next cube (new product development project entry point) and a “new development project”
is initiated.
 The new product will evolve through a number of iterations around the spiral, following the
path that bounds the region that has somewhat lighter shading than the core.

 In essence, the spiral, when characterized in this way, remains operative until the software is
retired. There are times when the process is dormant, but whenever a change is initiated, the
process starts at the appropriate entry point (e.g., product enhancement).
3.5 The WINWIN Spiral Model:

 The objective of this activity is to bring out project requirements from the customer.
 In ideal context the developer simply asks the customer what is required and the customer
provides sufficient details.
 In reality the customer and developer enter into a process of negotiation (give and take).

The best negotiations strive for a “win-win” result.That is,

 the customer wins by getting the system or product that satisfies the majority of the
customer’s needs and
 the developer wins by working to realistic and achievable budgets and deadlines.

Boehm’s WINWIN spiral model defines a set of negotiation activities at the beginning of each pass
around the spiral. Rather than a single customer communication activity, the following activities are
defined:
1. Identification of the system or subsystem’s key “stakeholders.” (A stakeholder is anyone in
the organization that has a direct business interest in the system or product to be built and
will be rewarded for a successful outcome or criticized if the effort fails.)
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win
conditions for all concerned (including the software project team).

The WINWIN spiral model introduces three process milestones, called anchor points , that help
establish the completion of one cycle around the spiral and provide decision milestones
before the software project proceeds.

 The first anchor point, life cycle objectives (LCO), defines a set of objectives for each major
software engineering activity.
 The second anchor point, life cycle architecture (LCA), establishes objectives
that must be met as the system and software architecture is defined.
 The third anchor point Initial operational capability (IOC) represents a set of objectives
associated with the preparation of the software for installation/distribution, site preparation
prior to installation, and assistance required by all parties that will use or support the
software.
3.6 The Concurrent Development Model:

The concurrent development model, sometimes called concurrent engineering, has been described
in the following manner by Davis and Sitaram.

 This provides an accurate state of the current state of a project.

 Focus on concurrent engineering activities in a software engineering process such as
prototyping, analysis modeling, requirements specification and design.
 Represented schematically as a series of major technical activities, tasks and their associated
states.
 Defined as a series of events that trigger transitions from state to state for each of the
software engineering activities.

There are two ways to achieve the concurrency:

1. System and component activities occur simultaneously and can be modeling using the state-
oriented approach.
2. A typical client/server application is implemented with many components; each can be
designed and realized concurrently.This is applicable to all types of software development
and provides an accurate picture of the current state of a project.

Diagram for Concurrency development model

3.7 Component Based Development:

 The component-based development (CBD) model incorporates many of the characteristics

of the spiral model.
 It is evolutionary in nature, demanding an iterative approach to the creation of software.
 The component-based development model composes applications from prepackaged
software components (called classes).
 Object-oriented technologies provide the technical framework for a component-based
process model for software engineering.
 The objectoriented paradigm emphasizes the creation of classes that encapsulate both data
and the algorithms used to manipulate the data.
 If properly designed and implemented, object-oriented classes are reusable across different
applications and computer-based system architectures.
 The engineering activity begins with the identification of candidate classes. This is
accomplished by examining the data to be manipulated by the application and the algorithms
that will be applied to accomplish the manipulation.Corresponding data and algorithms are
packaged into a class.

 The unified software development process is representative of a number of component-based

development models that have been proposed in the industry.
 Using the Unified Modeling Language (UML), the unified process defines the components
that will be used to build the system and the interfaces that will connect the components.

3.8 The Unified Process:

 Unified process is an attempt to draw on the best features and characteristics of conventional
software process models.
 It recognizes the importance of customer communication and makes more efficient methods
for describing the customer's view of a system.
 The Unified process can be characterized as phases.
The phases of Unified Process are:
1. Inception
2. Elaboration
3. Construction
4. Transition
5. Production

 Inception
 The Inception phase of a Unified Process includes both customer communication and
planning activities.
 By working together with the customer and end uers, the business requirements for the
software are identified, a rough architecture for the system is proposed.
 Elaboration
 Elobaration encompasses the customer communication and modeling activities.
 This will refines and expands the preliminary use cases that were developed as part of
the inception phase and expands the architectural representation to include five different
views of the software.
 They are: Use case model, analysis model, design model, implementation model and
deployment model.
 Construction
 The Construction phase develops the software components.
 As components are being implemented, unit tests are designed and executed for each
component.
 Transition
 Transition phase encompasses the later stages of construction activity and the first part
of the deployment activity.
 At the conclusion of the transition phase the software increments become a usable
software release.
 Production
◦ It coincides with the deployment activity. In this phase the on going use of the software
is monitored.
◦ Support for the infrastructure is provided, and defect reports and request for changes are
submitted and evaluated.