SUBJECT/COURSE:SOFTWARE ENGINEERING

YR/SEM: BTECH II YR II SEM SEC: IT-A

UNIT-1
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 is more than just a program code. A program is an executable code, which serves some
computational purpose. Software is considered to be a collection of executable programming code,
associated libraries and documentations. Software, when made for a specific requirement is called
software product.

Engineering on the other hand, is all about developing products, using well-defined, scientific principles
and methods. So, we can define software engineering as an engineering branch associated with the
development of software product using well-defined scientific principles, methods and procedures. The
outcome of software engineering is an efficient and reliable software product.

IEEE defines software engineering as: The application of a systematic, disciplined, quantifiable approach
to the development, operation and maintenance of software

NEED OF SOFTWARE ENGINEERING

The need of software engineering arises because of higher rate of change in user requirements and
environment on which the software is working.

Large software - It is easier to build a wall than to a house or building, likewise, as the size of software
become large engineering has to step to give it a scientific process.

Scalability- If the software process were not based on scientific and engineering concepts, it would be
easier to re-create new software than to scale an existing one.

Cost- As hardware industry has shown its skills and huge manufacturing has lower down the price of
computer and electronic hardware. But the cost of software remains high if proper process is not
adapted.

Dynamic Nature- The always growing and adapting nature of software hugely depends upon the
environment in which the user works. If the nature of software is always changing, new enhancements
need to be done in the existing one. This is where software engineering plays a good role.

Quality Management- Better process of software development provides better and quality software
product
EVOLVING ROLE OF SOFTWARE:

Software takes dual role. It is both a product and a vehicle for delivering a product. As a product: It
delivers the computing potential embodied by computer Hardware or by a network of computers. As a
vehicle: It is information transformer-producing, managing, acquiring, modifying, displaying, or
transmitting information that can be as simple as single bit or as complex as a multimedia presentation.
Software delivers the most important product of our time-information

. - It transforms personal data

- It manages business information to enhance competitiveness
- It provides a gateway to worldwide information networks
- It provides the means for acquiring information
The role of computer software has undergone significant change over a span of little more than 50
years - Dramatic Improvements in hardware performance
- Vast increases in memory and storage capacity
- A wide variety of exotic input and output options
1970s and 1980s:
Osbornecharacterized a “new industrial revolution”
• Toffler called the advent of microelectronics part of “the third wave of change” in human history
• Naisbitt predicted the transformation from an industrial society to an “information society”
• Feigenbaum and McCorduck suggested that information and knowledge would be the focal point for
power in the twenty-first century Stoll argued that the “electronic community” created by networks
and software was the key to
• knowledge interchange throughout the world
1990s began:
Toffier described a “power shift” in which old power structures disintegrate as computers and
• software lead to a “democratization of knowledge”. Yourdon worried that U.S companies might lose
their competitive edge in software related
• business and predicted “the decline and fall of the American programmer”. Hammer and Champy
argued that information technologies were to play a pivotal role in the
• “reengineering of the corporation”.
Mid-1990s:
The pervasiveness of computers and software spawned a rash of books by neo-luddites

Later 1990s:

Yourdon reevaluated the prospects of the software professional and suggested “the rise and
• resurrection” of the American programmer. The impact of the Y2K “time bomb” was at the end of
20th century
• 2000s progressed:
Johnson discussed the power of “emergence” a phenomenon that explains what happens when
• interconnections among relatively simple entities result in a system that “self-organizes to form more
intelligent, more adaptive behavior”. Yourdon revisited the tragic events of 9/11 to discuss the
continuing impact of global terrorism on the IT community Wolfram presented a treatise on a “new
kind of science” that posits a unifying theory based
• primarily on sophisticated software simulations Daconta and his colleagues discussed the evolution of
“the semantic web”
.• Today a huge software industry has become a dominant factor in the economies of the industrialized
world.
CHANGING NATURE OF SOFTWARE
The 7 broad categories of computer software present continuing challenges for software engineers:

1) System software
2) Application software
3) Engineering/scientific software
4) Embedded software
5) Product-line software
6) Web-applications
7) Artificial intelligence software.
System software: System software is a collection of programs written to service other programs. The
systems software 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 - multiple external interfaces E.g. compilers, editors and
file management utilities.
Application software: - Application software consists of standalone programs that solve a specific
business need. - It facilitates business operations or management/technical decision making. - It is used
to control business functions in real-time E.g. point-of-sale transaction processing, real-time
manufacturing process control.

Engineering/Scientific software: Engineering and scientific applications range - from astronomy to

volcanology - from automotive stress analysis to space shuttle orbital dynamics - from molecular biology
to automated manufacturing E.g. computer aided design, system simulation and other interactive
applications.

Embedded software: - 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. - It can perform
limited and esoteric functions or provide significant function and control capability.

E.g. Digital functions in automobile, dashboard displays, braking systems etc.

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 market place or address mass consumer
markets E.g. Word processing, spreadsheets, computer graphics, multimedia, entertainment, database
management, personal and business financial applications
Web-applications: WebApps are evolving into sophisticated computing environments that not only
provide standalone features, computing functions, and content to the end user, but also are integrated
with corporate databases and business applications.

Artificial intelligence software: AI software makes use of nonnumerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis. Application within this area
includes robotics, expert systems, pattern recognition, artificial neural networks, theorem proving, and
game playing.

The following are the new challenges on the horizon:

• Ubiquitous computing
• Netsourcing
• Open source
• The “new economy”

Ubiquitous computing: The challenge for software engineers will be to develop systems and application
software that will allow small devices, personal computers and enterprise system to communicate
across vast networks.

Net sourcing: The challenge for software engineers is to architect simple and sophisticated applications
that provide benefit to targeted end-user market worldwide.

Open Source: The challenge for software engineers is to build source that is self descriptive but more
importantly to develop techniques that will enable both customers and developers to know what
changes have been made and how those changes manifest themselves within the software.

The “new economy”: The challenge for software engineers is to build applications that will facilitate
mass communication and mass product distribution.

SOFTWARE CHARACTERISTICS

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 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 (see Chapter 24).
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.”

The relationship, often called the “bathtub curve,” indicates that hardware exhibits relatively
high failure rates early in its life;
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 1.2.
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!

During its life,2 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” . 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.

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

SOFTWARE MYTHS

Software myths—erroneous beliefs about software and the process that is used to build it—can be
traced to the earliest days of computing. Myths have a number of attributes that make them insidious.
most software engineering professionals recognize myths for what they are—misleading attitudes that
have caused serious problems for managers and practitioners alike.
Software engineering is a layered technology. Any engineering approach 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. Software engineering process is the glue that
holds the technology layers. Process defines a framework that must be established for effective delivery
of software engineering technology. The software forms the basis for management control of software
projects and establishes the context in which

- technical methods are applied,

 - work products are produced,
- milestones are established,
- quality is ensured,
- And change is properly managed.
Software engineering methods rely on a set of basic principles that govern area of the technology and
include modeling activities. 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. When tools are integrated so that information created by one tool can be used by another, a
system for the support of software development, called computer-aided software engineering, is
established.
A PROCESS FRAMEWORK:

• Software process must be established for effective delivery of software engineering

technology.
• A process framework establishes the foundation for a complete software process by
identifying a small number of framework activities that are applicable to all software
projects, regardless of their size or complexity.
• The process framework encompasses a set of umbrella activities that are applicable across
the entire software process.
• Each framework activity is populated by a set of software engineering actions
• Each software engineering action is 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.

In brief "A process defines who is doing what, when, and how to reach a certain goal."

A Process Framework

- establishes the foundation for a complete software process

- identifies a small number of framework activities
- applies to all s/w projects, regardless of size/complexity.
- also, set of umbrella activities –
applicable across entire s/w process.
- Each framework activity has - set of s/w engineering actions.
- Each s/w engineering action (e.g., design) has
- collection of related tasks (called task sets):
work tasks
work products (deliverables)
quality assurance points
project milestones.
, a 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

Generic Process Framework: It is applicable to the vast majority of software projects

- Communication activity
- Planning activity
- Modeling activity
- analysis action
- requirements gathering work task
- elaboration work task
- negotiation work task
- specification work task
- validation work task
- design action
- data design work task
- architectural design work task
- interface design work task
- component
-level design work task
- Construction activity
- Deployment activity

1) Communication: This framework activity involves heavy communication and collaboration with the
customer and encompasses requirements gathering and other related activities.
2) Planning: This activity establishes a plan for the software engineering work that follows. It describes
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.

3) Modeling: This activity encompasses the creation of models that allow the developer and customer to
better understand software requirements and the design that will achieve those requirements. The
modeling activity is composed of 2 software engineering actions- analysis and design.

• Analysis encompasses a set of work tasks.

• Design encompasses work tasks that create a design model.

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

5) Deployment: The software is delivered to the customer who evaluates the delivered product and
provides feedback based on the evolution.
These 5 generic framework activities can be used during the development of small programs, the
creation of large web applications, and for the engineering of large, complex computer-based systems.
The following are the set of Umbrella Activities

. 1) Software project tracking and control – allows the software team to assess progress against the
project plan and take necessary action to maintain schedule.

2) Risk Management - assesses risks that may effect the outcome of the project or the quality of the
product.

3) Software Quality Assurance - defines and conducts the activities required to ensure software quality.
4) Formal Technical Reviews - assesses software engineering work products in an effort to uncover and
remove errors before they are propagated to the next action or activity.

5) Measurement - define and collects process, project and product measures that assist the team in
delivering software that needs customer’s needs, can be used in conjunction with all other framework
and umbrella activities.

6) Software configuration management - manages the effects of change throughout the software
process.

7) Reusability management - defines criteria for work product reuse and establishes mechanisms to
achieve reusable components.

8) Work Product preparation and production - encompasses the activities required to create work
products such as models, document, logs, forms and lists.

Intelligent application of any software process model must recognize that adaption is essential for
success but process models do differ fundamentally in:

• The overall flow of activities and tasks and the interdependencies among activities and tasks
• The degree through which work tasks are defined within each frame work activity.
• The degree through which work products are identified and required.
• The manner which quality assurance activities are applied.
• The manner in which project tracking and control activities are applied.
• The overall degree of the detailed and rigor with which the process is described.
• The degree through which the customer and other stakeholders are involved with the project.
• The level of autonomy given to the software project team.
• The degree to which team organization and roles are prescribed

THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI):

The CMMI represents a process meta-model in two different ways:

• As a continuous model• As a staged model

.• Each process area is formally assessed against specific goals and practices and is rated according to
the following capability levels.

Level 0: Incomplete. The process area is either not performed or does not achieve all goals and
objectives defined by CMMI for level 1 capability.

Level 1: Performed. All of the specific goals of the process area have been satisfied. Work tasks
required to produce defined work products are being conducted.

Level 2: Managed. All level 1 criteria have been satisfied. In addition, all work associated with the
process area conforms to an organizationally defined policy; all people doing the work have access to
adequate resources to get the job done; stakeholders are actively involved in the process area as
required; all work tasks and work products are “monitored, controlled, and reviewed;

Level 3: Defined. All level 2 criteria have been achieved. In addition, the process is “tailored from the
organizations set of standard processes according to the organizations tailoring guidelines, and
contributes and work products, measures and other process-improvement information to the
organizational process assets”.

Level 4: Quantitatively managed. All level 3 criteria have been achieved. In addition, the process area is
controlled and improved using measurement and quantitative assessment.”Quantitative objectives for
quality and process performance are established and used as criteria in managing the process”

Level 5: Optimized. All level 4 criteria have been achieved. In addition, the process area is adapted and
optimized using quantitative means to meet changing customer needs and to continually improve the
efficacy of the process area under consideration”

The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to
achieve these goals. Specific practices refine a goal into a set of process-related activities.

The specific goals (SG) and the associated specific practices(SP) defined for project planning are

SG 1 Establish estimates

SP 1.1 Estimate the scope of the project

SP 1.2 Establish estimates of work product and task attributes
SP 1.3 Define project life cycle
SP 1.4 Determine estimates of effort and cost

SG 2 Develop a Project Plan

SP 2.1 Establish the budget and schedule

SP 2.2 Identify project risks
SP 2.3 Plan for data management
SP 2.4 Plan for needed knowledge and skills
SP 2.5 Plan stakeholder involvement
SP 2.6 Establish the project plan

SG 3 Obtain commitment to the plan

SP 3.1 Review plans that affect the project

SP 3.2 Reconcile work and resource levels
SP 3.3 Obtain plan commitment

In addition to specific goals and practices, the CMMI also defines a set of five generic goals and related
practices for each process area. Each of the five generic goals corresponds to one of the five capability
levels. Hence to achieve a particular capability level, the generic goal for that level and the generic
practices that correspond to that goal must be achieved. To illustrate, the generic goals (GG) and
practices (GP) for the project planning process area are

GG 1 Achieve specific goals

GP 1.1 Perform base practices

GG 2 Institutionalize a managed process

GP 2.1 Establish and organizational policy
GP 2.2 Plan the process
GP 2.3 Provide resources
GP 2.4 Assign responsibility
GP 2.5 Train people
GP 2.6 Manage configurations
GP 2.7 Identify and involve relevant stakeholders
GP 2.8 Monitor and control the process
GP 2.9 Objectively evaluate adherence
GP 2.10 Review status with higher level management

GG 3 Institutionalize a defined process

GP 3.1 Establish a defined process

GP 3.2 Collect improvement information

GG 4 Institutionalize a quantitatively managed process

GP 4.1 Establish quantitative objectives for the process

GP 4.2 Stabilize sub process performance

GG 5 Institutionalize and optimizing process

GP 5.1 Ensure continuous process improvement
GP 5.2 Correct root causes of problems

PROCESS PATTERNS
The software process can be defined as a collection patterns that define a set of activities, actions, work
tasks, work products and/or related behaviors required to develop computer software. A process
pattern provides us with a template- a consistent method for describing an important characteristic of
the software process. A pattern might be used to describe a complete process and a task within a
framework activity.
Pattern Name: The pattern is given a meaningful name that describes its function within the software
process.
Intent: The objective of the pattern is described briefly.
Type: The pattern type is specified. There are three types

1. Task patterns define a software engineering action or work task that is part of the process and
relevant to successful software engineering practice. Example: Requirement Gathering
2. Stage Patterns define a framework activity for the process. This pattern incorporates multiple task
patterns that are relevant to the stage. Example: Communication
3. Phase patterns define the sequence of framework activities that occur with the process, even when
the overall flow of activities is iterative in nature. Example: Spiral model or prototyping.

Initial Context: The conditions under which the pattern applies are described prior to the initiation of
the pattern, we ask
(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
Problem: The problem to be solved by the pattern is described.
Solution: The implementation of the pattern is described. This section describes how the initial state of
the process is modified as a consequence 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

Resulting Context: The conditions that will result once the pattern has been successfully implemented
are described. Upon completion of the pattern we ask
(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?

Known Uses: The specific instances in which the pattern is applicable are indicated Process patterns
provide and effective mechanism for describing any software process. The patterns enable a software
engineering organization to develop a hierarchical process description that begins at a high-level of
abstraction. Once process pattern have been developed, they can be reused for the definition of process
variants-that is, a customized process model can be defined by a software team using the pattern as
building blocks for the process models.

PROCESS ASSESSMENT

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. In addition, the process itself should be assessed to be essential 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 have been proposed over the past
few decades.
Standards CMMI Assessment Method for Process Improvement (SCAMPI) provides a five step process
assessment model that incorporates initiating, diagnosing, establishing, acting & 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, using the SEI CMM as the basis for the
assessment.
SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessments. 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 is a generic standard that applies to any organization that wants to improve
the overall quality of the products, system, or services that it provides. Therefore, the standard is
directly applicable to software organizations &companies.

PERSONAL AND TEAM PROCESS MODELS:

The best software process is one that is close to the people who will be doing the work.Each software
engineer would create a process that best fits his or her needs, and at the same time meets the broader
needs of the team and the organization. Alternatively, the team itself would create its own process, and
at the same time meet the narrower needs of individuals and the broader needs of the organization.

Personal software process (PSP) emphasizes personal measurement of both the work product that is
produced and the resultant quality of the work product.

The PSP process model defines five framework activities: planning, high-level design, high level design
review, development, and postmortem.
Planning: This activity isolates requirements and, base on these develops both size and resource
estimates. In addition, a defect estimate 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 task and work results.
Postmortem: Using the measures and metrics collected the effectiveness of the process is determined.
Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
PSP stresses the need for each software engineer to identify errors early and, as important, to
understand the types of errors that he is likely to make. PSP represents a disciplined, metrics-based
approach to software engineering.

Team software process (TSP): The goal of TSP is to build a “self-directed project team that organizes
itself to produce high-quality software.
The following are the 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(IPT) 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 CMM level 5 behavior normal and expected

Provide improvement guidance to high-maturity organizations.

• Facilitate university teaching of industrial-grade team skills.
A self-directed team defines
- roles and responsibilities for each team member
- tracks quantitative project data
- identifies a team process that is appropriate for the project
- a strategy for implementing the process
- defines local standards that are applicable to the teams software engineering work;
- continually assesses risk and reacts to it
- Tracks, manages, and reports project status.

TSP defines the following framework activities: launch, high-level design, implementation, integration
and test, and postmortem.
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 and other more detailed work functions that are part of the
team process.
Each project is “launched” using a sequence of tasks.
The following launch script is recommended
• Review project objectives with management and agree on and document team goals
• Establish team roles
• Define the teams development process
• Make a quality plan and set quality targets
• Plan for the needed support facilities

PROCESS MODELS
Prescriptive process models define a set of activities, actions, tasks, milestones, and work products that
are required to engineer high-quality software. These process models are not perfect, but they do
provide a useful roadmap for software engineering work. A prescriptive process model populates a
process framework with explicit task sets for software engineering actions.
THE WATERFALL MODEL: 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.
Context: Used when requirements are reasonably well understood.
Advantage: It can serve as a useful process model in situations where requirements are fixed and work
is to proceed to complete in a linear manner.

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 exist at the beginning of many
projects.
3. The customer must have patience. A working version of the programs will not be available until late in
the project time-span. If a major blunder is undetected then it can be disastrous until the program is
reviewed.

Feasibility study - The main aim of feasibility study is to determine whether it would be financially and
technically feasible to develop the product.
• At first project managers or team leaders try to have a rough understanding of what is required
to be done by visiting the client side. They study different input data to the system and output
data to be produced by the system. They study what kind of processing is needed to be done on
these data and they look at the various constraints on the behavior of the system.
• After they have an overall understanding of the problem they investigate the different solutions
that are possible. Then they examine each of the solutions in terms of what kind of resources
required, what would be the cost of development and what would be the development time for
each solution.
• Based on this analysis they pick the best solution and determine whether the solution is feasible
financially and technically. They check whether the customer budget would meet the cost of the
product and whether they have sufficient technical expertise in the area of development.
Requirements analysis and specification: - The aim of the requirements analysis and specification phase
is to understand the exact requirements of the customer and to document them properly. This phase
consists of two distinct activities, namely
• Requirements gathering and analysis
• Requirements specification
The goal of the requirements gathering activity is to collect all relevant information from the customer
regarding the product to be developed. This is done to clearly understand the customer requirements so
that incompleteness and inconsistencies are removed.
The requirements analysis activity is begun by collecting all relevant data regarding the product to be
developed from the users of the product and from the customer through interviews and discussions. For
example, to perform the requirements analysis of a business accounting software required by an
organization, the analyst might interview all the accountants of the organization to ascertain their
requirements. The data collected from such a group of users usually contain several contradictions and
ambiguities, since each user typically has only a partial and incomplete view of the system. Therefore it
is necessary to identify all ambiguities and contradictions in the requirements and resolve them through
further discussions with the customer. After all ambiguities, inconsistencies, and incompleteness have
been resolved and all the requirements properly understood, the requirements specification activity can
start. During this activity, the user requirements are systematically organized into a Software
Requirements Specification (SRS) document. The customer requirements identified during the
requirements gathering and analysis activity are organized into a SRS document. The important
components of this document are functional requirements, the nonfunctional requirements, and the
goals of implementation.

Design: - The goal of the design phase is to transform the requirements specified in the SRS document
into a structure that is suitable for implementation in some programming language. In technical terms,
during the design phase the software architecture is derived from the SRS document. Two distinctly
different approaches are available: the traditional design approach and the object-oriented design
approach. Traditional design approach -Traditional design consists of two different activities; first• a
structured analysis of the requirements specification is carried out where the detailed structure of the
problem is examined. This is followed by a structured design activity. During structured design, the
results of structured analysis are transformed into the software design. Object-oriented design
approach -In this technique, various objects that occur in the• problem domain and the solution domain
are first identified, and the different relationships that exist among these objects are identified. The
object structure is further refined to obtain the detailed design.
Coding and unit testing:-The purpose of the coding phase (sometimes called the implementation
phase) of software development is to translate the software design into source code. Each component
of the design is implemented as a program module. The end-product of this phase is a set of program
modules that have been individually tested. During this phase, each module is unit tested to determine
the correct working of all the individual modules. It involves testing each module in isolation as this is
the most efficient way to debug the errors identified at this stage.
Integration and system testing: -Integration of different modules is undertaken once they have been
coded and unit tested. During the integration and system testing phase, the modules are integrated in a
planned manner. The different modules making up a software product are almost never integrated in
one shot. Integration is normally carried out incrementally over a number of steps. During each
integration step, the partially integrated system is tested and a set of previously planned modules are
added to it. Finally, when all the modules have been successfully integrated and tested, system testing is
carried out. The goal of system testing is to ensure that the developed system conforms to its
requirements laid out in the SRS document. System testing usually consists of three different kinds of
testing activities:
α – testing: It is the system testing performed by the development team.
• β –testing: It is the system testing performed by a friendly set of customers.
• Acceptance testing: It is the system testing performed by the customer himself after the product
delivery to determine whether to accept or reject the delivered product.

System testing is normally carried out in a planned manner according to the system test plan document.
The system test plan identifies all testing-related activities that must be performed, specifies the
schedule of testing, and allocates resources. It also lists all the test cases and the expected outputs for
each test case.
Maintenance: -Maintenance of a typical software product requires much more than the effort necessary
to develop the product itself. Many studies carried out in the past confirm this and indicate that the
relative effort of development of a typical software product to its maintenance effort is roughly in the
40:60 ratios. Maintenance involves performing any one or more of the following three kinds of activities:

• Correcting errors that were not discovered during the product development phase. This is•
called corrective maintenance.
• Improving the implementation of the system, and enhancing the functionalities of the• system
according to the customer’s requirements. This is called perfective maintenance.
• Porting the software to work in a new environment. For example, porting may be• required to
get the software to work on a new computer platform or with a new operating system. This is
called adaptive maintenance.

Shortcomings of the classical waterfall model

The classical waterfall model is an idealistic one since it assumes that no development error is ever
committed by the engineers during any of the life cycle phases. However, in practical development
environments, the engineers do commit a large number of errors in almost every phase of the life cycle.
The source of the defects can be many: oversight, wrong assumptions, use of inappropriate technology,
communication gap among the project engineers, etc. These defects usually get detected much later in
the life cycle. For example, a design defect might go unnoticed till we reach the coding or testing phase.
Once a defect is detected, the engineers need to go back to the phase where the defect had occurred
and redo some of the work done during that phase and the subsequent phases to correct the defect and
its effect on the later phases. Therefore, in any practical software development work, it is not possible
to strictly follow the classical waterfall model.

THE INCREMENTAL MODEL:

Context: 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, additional staff can be added to
implement the next increment. In addition, increments can be planned to manage technical risks.
 • The incremental model combines elements of the waterfall model applied in an iterative
fashion.

• The incremental model delivers a series of releases called increments that provide progressively
more functionality for the customer as each increment is delivered.

• When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed. The core product is used by the customer. 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.

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.

To overcome the major shortcomings of the classical waterfall model, we come up with the iterative
waterfall model.
Here, we provide feedback paths for error correction as & when detected later in a phase. Though
errors are inevitable, but it is desirable to detect them in the same phase in which they occur. If so, this
can reduce the effort to correct the bug.

The advantage of this model is that there is a working model of the system at a very early stage of
development which makes it easier to find functional or design flaws. Finding issues at an early stage of
development enables to take corrective measures in a limited budget.

The disadvantage with this SDLC model is that it is applicable only to large and bulky software
development projects. This is because it is hard to break a small software system into further small
serviceable increments/modules.
Difference: The incremental process model, like prototyping and other evolutionary approaches, is
iterative in nature. But unlike prototyping, the incremental model focuses on delivery of an operational
product with each increment
THE RAD MODEL: Rapid Application Development (RAD) is an incremental software process model that
emphasizes a short development cycle. The RAD model is a “high-speed” adaption of the waterfall
model, in which rapid development is achieved by using a component base construction approach.
Context: If requirements are well understood and project scope is constrained, the RAD process enables
a development team to create a “fully functional system” within a very short time period.

The RAD approach maps into the generic framework activities.

Communication works to understand the business problem and the information characteristics that the
software must accommodate.
Planning is essential because multiple software teams works in parallel on different system functions.
Modeling encompasses three major phases- business modeling, data modeling and process modeling-
and establishes design representation that serve existing software components and the application of
automatic code generation.
Deployment establishes a basis for subsequent iterations.
The RAD approach has drawbacks:
For large, but scalable projects, RAD requires sufficient human resources to create the right number of
RAD teams.
If developers and customers are not committed to the rapid-fire activities necessary to complete the
system in a much abbreviated time frame, RAD projects will fail

If a system cannot be properly modularized, building the components necessary for RAD will be
problematic

If high performance is an issue, and performance is to be achieved through tuning the interfaces to
system components, the RAD approach may not work; and RAD may not be appropriate when technical
risks are high.

EVOLUTIONARY PROCESS MODELS:

 Evolutionary process models produce with each iteration produce an increasingly more complete
version of the software with every iteration.

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

PROTOTYPING:

Prototyping is more commonly used as a technique that can be implemented within the context of
anyone of the process model. The prototyping paradigm begins with communication. The software
engineer and customer meet and define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further definition is mandatory. Prototyping iteration
is planned quickly and modeling occurs. The quick design leads to the construction of a prototype. The
prototype is deployed and then evaluated by the customer/user. Iteration occurs as the prototype is
tuned to satisfy the needs of the customer, while at the same time enabling the developer to better
understand what needs to be done.

Context: If a customer defines a set of general objectives for software, but does not identify detailed
input, processing, or output requirements, in such situation prototyping paradigm is best approach. If a
developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system then
he can go for this prototyping method.
Advantages: The prototyping paradigm assists the software engineer and the customer to better
understand what is to be built when requirements are fuzzy. The prototype serves as a mechanism for
identifying software requirements. If a working prototype is built, the developer attempts to make use
of existing program fragments or applies tools.
Prototyping can be problematic for the following reasons:

1. The customer sees what appears to be a working version of the software, unaware that the
prototype is held together “with chewing gum and baling wire”, unaware that in the rush to get it
working we 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, the
customer cries foul and demands that “a few fixes” be applied to make the prototype a working
product. Too often, software development relents.

2. The developer often makes 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, the developer 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.

Prototype A prototype is a toy implementation of the system. A prototype usually exhibits

limited functional capabilities, low reliability, and inefficient performance compared to the
actual software. A prototype is usually built using several shortcuts. The shortcuts might involve
using inefficient, inaccurate, or dummy functions. The shortcut implementation of a function,
for example, may produce the desired results by using a table look-up instead of performing the
actual computations. A prototype usually turns out to be a very crude version of the actual
system.
Need for a prototype in software development
There are several uses of a prototype. An important purpose is to illustrate the input data
formats, messages, reports, and the interactive dialogues to the customer. This is a valuable
mechanism for gaining better understanding of the customer’s needs:
• how the screens might look like
• how the user interface would behave
• how the system would produce outputs

Another reason for developing a prototype is that it is impossible to get the perfect product in the first
attempt. Many researchers and engineers advocate that if you want to develop a good product you
must plan to throw away the first version. The experience gained in developing the prototype can be
used to develop the final product. A prototyping model can be used when technical solutions are
unclear to the development team. A developed prototype can help engineers to critically examine the
technical issues associated with the product development. Often, major design decisions depend on
issues like the response time of a hardware controller, or the efficiency of a sorting algorithm, etc. In
such circumstances, a prototype may be the best or the only way to resolve the technical issues.

A prototype of the actual product is preferred in situations such as:

• User requirements are not complete
 • Technical issues are not clear

THE 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 waterfall model.
• The spiral model can be adapted to apply throughout the entire life cycle of an application,
from concept development to maintenance.
• Using the spiral model, software is developed in a series of evolutionary releases. During
early iterations, the release might be a paper model or prototype. During later iterations,
increasingly more complete versions of the engineered system are produced.

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.
The first circuit around the spiral might result in the development of 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.
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.
The first circuit around the spiral might represent a “concept development project” which
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. Later, a circuit around the spiral might be used to represent a “product
enhancement project.” In essence, the spiral, when characterized in this way, remains
operative until the software is retired.
 Context: The spiral model can be adopted to apply throughout the entire life cycle of an
application, from concept development to maintenance.
Advantages: It provides the potential for rapid development of increasingly more complete
versions of the software.

The spiral model is a realistic approach to the development of large-scale systems and
software. The spiral model uses prototyping as a risk reduction mechanism but, more
importantly enables the developer to apply the prototyping approach at any stage in the
evolution of the product.
Draw Backs: The spiral model is not a panacea. It may be difficult to convince customers
that the evolutionary approach is controllable. It demands considerable risk assessment
expertise and relies on this expertise for success. If a major risk is not uncovered and
managed, problems will undoubtedly occur.

The Spiral model of software development is shown in fig. 4.1. The diagrammatic
representation of this model appears like a spiral with many loops. The exact number of
loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software
process. For example, the innermost loop might be concerned with feasibility study, the
next loop with requirements specification, the next one with design, and so on. Each phase
in this model is split into four sectors (or quadrants) as shown in fig. 4.1. The following
activities are carried out during each phase of a spiral model.

First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.
Second Quadrant (Risk Assessment and Reduction)
• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks.
For example, if there is a risk that the requirements are inappropriate, a prototype system
may be developed.
Third Quadrant (Development and Validation)
 • Develop and validate the next level of the product after resolving the identified risks.
Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and plan the next iteration around
the spiral.
• Progressively more complete version of the software gets built with each iteration
around the spiral.
Circumstances to use spiral model
The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However,
this model is much more complex than the other models – this is probably a factor
deterring its use in ordinary projects.
Comparison of different life-cycle models
The classical waterfall model can be considered as the basic model and all other life cycle
models as embellishments of this model. However, the classical waterfall model cannot be
used in practical development projects, since this model supports no mechanism to handle
the errors committed during any of the phases.
This problem is overcome in the iterative waterfall model. The iterative waterfall model is
probably the most widely used software development model evolved so far. This model is
simple to understand and use. However this model is suitable only for well-understood
problems; it is not suitable for very large projects and for projects that are subject to many
risks.
The prototyping model is suitable for projects for which either the user requirements or the
underlying technical aspects are not well understood. This model is especially popular for
development of the user-interface part of the projects.

The evolutionary approach is suitable for large problems which can be decomposed into a
set of modules for incremental development and delivery. This model is also widely used for
objectoriented development projects. Of course, this model can only be used if the
incremental delivery of the system is acceptable to the customer.

The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However,
this model is much more complex than the other models – this is probably a factor
deterring its use in ordinary projects.

The different software life cycle models can be compared from the viewpoint of the
customer. Initially, customer confidence in the development team is usually high
irrespective of the development model followed. During the lengthy development process,
customer confidence normally drops off, as no working product is immediately visible.
Developers answer customer queries using technical slang, and delays are announced. This
gives rise to customer resentment. On the other hand, an evolutionary approach lets the
customer experiment with a working product much earlier than the monolithic approaches.
Another important advantage of the incremental model is that it reduces the customer’s
trauma of getting used to an entirely new system. The gradual introduction of the product
via incremental phases provides time to the customer to adjust to the new product. Also,
from the customer’s financial viewpoint, incremental development does not require a large
upfront capital outlay. The customer can order the incremental versions as and when he
can afford them