SOFTWARE ENGINEERING

MODULE 1
CHAPTER 1

Dr Dayanand J

1
 CHAPTER 1
OBJECTIVES
The objectives of this module are:
• To discuss the importance of Software Engineering
• To discuss the development of different types of software systems that require
different software engineering techniques
• To discuss some ethical and professional issues that are important for software
engineers
• To discuss the concepts of software processes, software process models, and
Rational Unified process
• To discuss the fundamental process activities of software requirements
engineering, software development, testing, and evolution.
• To discuss the concept of user and system requirements, Functional
requirements and Non-Functional requirements.
• To discuss the principal requirements engineering activities of elicitation,
analysis, validation and requirements documentation.
2
 CHAPTER 1
INTRODUCTION
• The notion of software engineering was first proposed in 1968 at a conference
• To discuss about the ‘Software Crisis’
• Individual approaches to program development did not scale up to large and
complex software systems.

These were:
• unreliable,
• cost more than expected, and
• were delivered late.
• During 1970s to 1980s, a variety of new software engineering techniques and
methods such as structured programming, information hiding and object-oriented
development were developed
• Tools and standard notations were developed and are now extensively used. 3
• There are still many reports of software projects going wrong, and ‘Software
failures’.
• Software engineering is criticized as inadequate for modern software
development.
• However, many of these so-called software failures are a consequence of two
factors:
1. Increasing Demands: Systems have to be built and delivered more quickly;
larger, even more complex systems
2. Low Expectations:
a. It is relatively easy to write computer programs without using software
engineering methods and techniques.
b. Consequently, their software is more often more expensive and less reliable than
it should be.
c. We need better software engineering education and training to address this problem.

Compare OS, System Software, and Application Software

Why Development of OS & SS is slow phase, and Application software is very
4
fast
 1.1 THE NATURE OF SOFTWARE

• Today, software takes on a dual role.

• It is a product and, at the same time, the vehicle for delivering a product.
• Software is an information transformer producing, managing, acquiring,
modifying, displaying, or transmitting information that can be as simple as
a single bit or as complex as a multimedia presentation.
• As the vehicle used to deliver the product.
• Software acts as the basis for the control of the computer (operating
systems), the communication of information (networks), and the creation
and control of other programs (software tools and environments).
• The role of computer software has undergone significant change over a
time span of little more than 50 years.
• Dramatic improvements in hardware performance, pro-found changes in
computing architectures, vast increases in memory and storage capacity,
and a wide variety of exotic input and output options have all precipitated
more sophisticated and complex computer-based systems.

5
• The lone programmer of an earlier era has been replaced by a team of
software specialists, each focusing on one part of the technology required
to deliver a complex application.
• Yet, the same questions asked of the lone programmer are being asked
when modern computer-based systems are built:
• Why does it take so long to get software finished?
• Why are development costs so high?
• Why can't we find all the errors before we give the software to customers?
• Why do we continue to have difficulty in measuring progress as software
is being developed?

6
 SOFTWARE
• Definition of Software is
• (1) instructions (computer programs) that when executed provide desired
function and performance
• (2) data structures that enable the programs to adequately manipulate
information,
• (3) documents that describe the operation and use of the programs.
• Software Characteristics
• To gain an understanding of software it is important to examine the
characteristics of software that make it different from other things that
human beings build.
• When hardware is built, the human creative process (analysis, design,
construction, testing) is ultimately translated into a physical form.
• Software is a logical rather than a physical system element.
• Therefore, software has characteristics that are considerably different than
those of hardware:

7
• Software is developed or engineered, it is not manufactured in the classical
sense.
• Although some similarities exist between software development and
hardware manufacture, the two activities are fundamentally different.
• Both activities, high quality is achieved through good design, but the
manufacturing phase for hardware can introduce quality problems that are
easily corrected
• For software Both activities are dependent on people, but the relationship
between people applied and work accomplished is entirely different.
• Both activities require the construction of a "product" but the approaches
are different.
• Software costs are concentrated in engineering.
• This means that software projects cannot be managed as if they were
manufacturing projects.

8
• Characteristics of software:
There is some characteristic of software which is given below:
• Reliability: The ability of the software to consistently perform its intended
tasks without unexpected failures or errors.
• Usability: How easily and effectively users can interact with and navigate
through the software.
• Efficiency: The optimal utilization of system resources to perform tasks on
time.
• Maintainability: How easily and cost-effectively software can be
modified, updated, or extended.
• Portability: The ability of software to run on different platforms or
environments without requiring significant modifications.

9
• 2. Software doesn't "wear out.“

Figure 1.1 depicts failure rate as a function of time for hardware

• Hardware exhibits relatively high failure rates early in its life (these
failures are often attributable to design or manufacturing defects);
• Defects are corrected and the failure rate drops to a steady-state level
(ideally, quite low) for some period of time.
• As time passes, however, the failure rate rises again as hardware
components suffer from the cumulative affects of dust, vibration, abuse,
temperature extremes, and many other environmental maladies.
• . Stated simply, the hardware begins to wear out
10
 • 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”

Figure 1.2. During its life, software will undergo change (maintenance).
• Undiscovered defects will cause high failure rates early in the life of a program.
• However, these are corrected (ideally, without introducing other errors) and the
curve flattens as shown.
• However, the implication is clear—software doesn't wear out. But it does
deteriorate!
• Although the industry is moving toward component-based assembly, most
11
software continues to be custom built.
 Software Applications

• Software may be applied in any situation for which a prespecified set of

procedural steps (i.e., an algorithm) has been defined
• Information content and determinacy are important factors in determining
the nature of a software application.
• Content refers to the meaning and form of incoming and outgoing
information.
• For example, many business applications use highly structured input data
(a database) and produce formatted “reports.”
• Software that controls an automated machine (e.g., a numerical control)
accepts discrete data items with limited structure and produces individual
machine commands in rapid succession.
• Information determinacy : refers to the predictability of the order and
timing of information.
• An engineering analysis program accepts data that have a predefined order,
executes the analysis algorithm(s) without interruption, and produces
resultant data in report or graphical format.

12
 Software Application Domains
• System software. System software is a collection of programs written to
service other programs.
• The system software area is characterized by heavy interaction with
computer hardware;
• Heavy usage by multiple users; concurrent operation that requires
scheduling, resource sharing, and sophisticated process management;
complex data structures; and multiple external interfaces. Ex. Compiler…
• Real-time software. Software that monitors/analyzes/controls real-world
events as they occur is called real time. For ex. Weather Forecasting
• Business software. Business information processing is the largest single
software application area. Example: point of sale terminal
• Engineering and scientific software. Engineering and scientific software
have been characterized by "number crunching" algorithms. Ex. Matlab
• Applications range from astronomy to volcanology, from automotive stress
analysis to space shuttle orbital dynamics, and from molecular biology to
automated manufacturing
• How ever modern applications use Computer-aided design, system
simulation, and other interactive applications to take on real-time and even
system software characteristics. 13
• Embedded software. Intelligent products have become commonplace in
nearly every consumer and industrial market. Embedded software resides
in read-only memory and is used to control products and systems for the
consumer and industrial markets ex. Washing Machine , A/C control, oven
etc
• Personal computer software. The personal computer software market
has burgeoned over the past two decades.
• Word processing, spreadsheets, computer graphics, multimedia,
entertainment, database management, personal and business financial
applications, external network, and database access are only a few of
hundreds of applications.
• Web-based software. The Web pages retrieved by a browser are software
that incorporates executable instructions (e.g., HTML, Perl, or Java), and
data (e.g., hypertext and a variety of visual and audio formats).
• Artificial intelligence software. Artificial intelligence (AI) software
makes use of non numerical algorithms to solve complex problems that are
not amenable to computation or straightforward analysis
• ex. Gaming applications
14
 Legacy Software
• Software developed decades ago and have been continually
modified to meet changes in business requirements and
computing platforms.
• The proliferation of such systems is causing headaches for
large organizations who find them costly to maintain and risky
to evolve.
• Legacy systems sometimes have inextensible designs,
convoluted code, poor or nonexistent documentation, test
cases and results that were never archived.
• ” What to do?
• Do nothing, at least until the legacy system must undergo
some significant change

15
 1.2 The Unique Nature of Web Apps
• It is a client-server computer program that the client runs on
the web browser.
• In their simplest form, Web apps can be little more than a set
of linked hypertext files that present information using text
and limited graphics.
• However, as e-commerce and B2B applications grow in
importance.
• Web apps are evolving into a sophisticated computing
environment that not only provides a standalone feature,
computing function, and content to the end user.

16
 The following attributes are encountered in the vast majority of WebApps

• Network intensiveness A WebApp resides on a network and

must serve the needs of a diverse community of clients. The
network may enable worldwide access and communication.
• Concurrency A large number of users may access the WebApp
at one time.
• Unpredictable load The number of users of the WebApp may
vary by orders of magnitude from day to day
• Performance If a WebApp user must wait too long (for access,
for serverside processing, for client-side formatting and
display), he or she may decide to go elsewhere
• Availability Although expectation of 100 percent availability is
unreasonable users of popular WebApps often demand access
on a 24/7/365 basis.
17
• Data driven The primary function of many WebApps is to use
hypermedia to present text, graphics, audio, and video
content to the end user.
• Content sensitive The quality and aesthetic nature of content
remains an important determinant of the quality of a
WebApp.
• Continuous evolution Unlike conventional application
software that evolves over a series of planned, chronologically
spaced releases, Web applications evolve continuously.
• Immediacy WebApps often exhibit a time-to-market that can
be a matter of a few days or weeks.
• Security Because WebApps are available via network access, it
is difficult, if not impossible, to limit the population of end
users who may access the application

18
1.3 Software Engineering
What is it?
• Software engineering encompasses a process, a collection of methods
(practice) and an array of tools that allow professionals to build high-quality
computer software.
• Software engineers apply the software engineering process.
Why is it important?
• Software engineering is important because it enables us to build complex
systems in a timely manner and with high quality.
• It imposes discipline to work that can become quite chaotic, but it also
allows the people who build computer software to adapt their approach in a
manner that best suits their need.
What are the steps?
• You build computer software like you build any successful product, by
applying an agile, adaptable process that leads to a high-quality result that
meets the needs of the people who will use the product.
• You apply a software engineering approach.
19
• Individuals, businesses, and governments increasingly rely on software for
strategic and tactical decision making as well as day-to-day operations and
control.
• If the software fails, people and major enterprises can experience anything
from minor inconvenience to catastrophic failures.
• It follows that software should exhibit high quality.
• Software Engineering Defination:
The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the
application of engineering to software.
• We need discipline, but we also need adaptability and agility.
• Software engineering is a layered technology.

20
 Software engineering layers

• Continuous process improvement culture ultimately leads to the development

of increasingly more effective approaches to software engineering.
• The bedrock that supports software engineering is a quality focus.
• The foundation for software engineering is the process layer.
• The software engineering process is the glue that holds the technology layers
together and enables rational and timely development of computer software.

21
• Process defines a framework that must be established for effective delivery
of software engineering technology.
• The software process forms the basis for management control of software
projects.
• Software engineering methods provide the technical how-to’s for building
software.
• Methods encompass a broad array of tasks that include communication,
requirements analysis, design modeling, program construction, testing, and
support.
• It also include modeling activities and other descriptive techniques.
• 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.

22
 1.4 The Software Process
• A process is a collection of activities, actions, and tasks that are performed when
some work product is to be created.
• An activity strives to achieve a broad objective (e.g., communication with
stakeholders) and is applied regardless of the application domain, size of the
project, complexity of the effort, or degree of rigor with which software
engineering is to be applied.
• An action (e.g., architectural design) encompasses a set of tasks that produce a
major work product (e.g., an architectural model).
• A task focuses on a small, but well-defined objective (e.g., conducting a unit test)
that produces a tangible outcome.
What is it?
• When you work to build a product or system, it’s important to go through a series
of predictable steps—a road map that helps you create a timely, high-quality result.
• The road map that you follow is called a “software process.”

23
 1.4 The Software Process
• A process frame work is the foundation for a complete software
engineering process by identifying a small number of framework activities
that are applicable to all software projects.
• A generic process framework for software engineering encompasses five
activities:
1. Communication. Before any technical work can commence, it is critically
important to communicate and collaborate with the customer
• The intent is to understand stakeholders’ objectives for the project and to
gather requirements that help define software features and functions.
2. Planning.
• Any complicated journey can be simplified if a map exists.
• The map called a software project plan defines the software engineering
work by describing the technical tasks to be conducted, the risks that are
likely, the resources that will be required, the work products to be
produced, and a work schedule.

24
3. Modeling.
• Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a
carpenter, or an architect, you work with models every day.
• You create a “sketch” of the thing so that you’ll understand the big
picture—what it will look like architecturally,
• A software engineer does the same thing by creating models to better
understand software requirements and the design that will achieve those
requirement
4. Construction.
• What you design must be built.
• This activity combines code generation (either manual or automated) and
the testing that is required to uncover errors in the code.
5. Deployment.
• The software (as a complete entity or as a partially completed increment)
is delivered to the customer who evaluates the delivered product and
provides feedback based on the evaluation.

25
 1.5 The Software Engineering Practice
• In a classic book, How to Solve It ?
• written before modern computers existed, George Polya
outlined the essence of problem solving, and consequently,
the essence of software engineering practice:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4.Examine the result for accuracy (testing and quality assurance).

26
 General Principles
• Word principle as “an important underlying law or assumption
required in a system of thought.”
• There are seven principles that focus on software engineering
practice as a whole
• The First Principle: The Reason It All Exists
• : to provide value to its users. All decisions should be made
with this in mind
• ask yourself questions such as: “Does this add real value to
the system?” If the answer is “no,” don’t do it.
• All other principles support this one.

27
• The Second Principle: KISS (Keep It Simple, Stupid!)
• All design should be as simple as possible, but no simpler i.e
more easily understood and easily maintained system.
• The more elegant designs are usually the more simple ones.
• The Third Principle: Maintain the Vision
• A clear vision is essential to the success of a software project.
• Compromising the architectural vision of a software system
weakens and will eventually break even the well-designed
systems.
• The Fourth Principle: What You Produce, Others Will Consume
• Always specify, design, and implement knowing someone else
will have to understand what you are doing.
• Making their job easier adds value to the system.

28
• The Fifth Principle: Be Open to the Future
• A system with a long lifetime has more value.
• In today’s computing environments, where specifications
change on a moment’s notice and hardware platforms are
obsolete just a few months old, software lifetimes are
typically measured in months instead of years.
• These systems must be ready to adapt to these and other
changes.
• The Sixth Principle: Plan Ahead for Reuse
• Reuse saves time and effort.
• The reuse of code and designs has been proclaimed as a
major benefit of using object-oriented technologies
• Planning ahead for reuse reduces the cost and increases the
value of both the reusable components and the systems into
which they are incorporated.
29
• The Seventh principle: Think!
• Placing clear, complete thought before action almost always
produces better results.
• When you think about something, you are more likely to do it
right.
• If you do think about something and still do it wrong, it
becomes a valuable experience

30
1.6 Software Myths
MYTH
• Myths are stories shared by a group.
• A part of that group's cultural identity.
• e.g : Prometheus Bring Fire to Mankind.
• Usually myth is related to the area of lies

WHAT IS SOFTWARE MYTH ?

• Beliefs about software and the process used to build it.
• Software myths propagated misinformation and confusions.

TYPE OF SOFTWARE MYTHS

• MANAGEMENT MYTHS
• CUSTOMER MYTHS
• PRACTITIONER’S MYTHS
31
Management Myths

32
Customer myths

33
Practitioner’s myths

34
 Chapter 2

PROCESSES MODELS

35
 2.1 A Generic Process Model
• a process was defined as a collection of
work activities, actions, and tasks that are
performed when some work product is to
be created.
• Each of these activities, actions, and tasks
resides within a framework or model that
defines their relationship with the process
and with one another.
• The software process is represented
schematically in Figure 3.1 .
• Referring to the figure, each framework
activity is populated by a set of software
engineering actions.
• a generic process framework for software
engineering defines five framework
activities— communication, planning,
modeling, construction, and deployment
36
 Process Flow
• In addition, a set of umbrella activities project tracking and control, risk
management, quality assurance, configuration management, technical
reviews, and others—are applied throughout the process
• Process flow describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect
to sequence and time.
• Linear Process Flow and iterative process flow

37
• An evolutionary process flow executes the activities in a “circular”
manner. Each circuit through the five activities leads to a more complete
version of the software ( Figure 3.2c) .
• A parallel process flow ( Figure 3.2d) executes one or more activities in
parallel with other activities

38
 Process Patterns
• Every software team encounters problems as it moves through the software
process.
• It would be useful if proven solutions to these problems were readily
available to the team so that the problems could be addressed and resolved
quickly.
• A process pattern describes a process related problem that is encountered
during software engineering work, identifies the environment in which the
problem has been encountered, and suggests one or more proven solutions
to the problem.
• Stated in more general terms, a process pattern provides you with a
template a consistent method for describing problem solutions within the
context of the software process.
• Patterns can be defined at any level of abstraction.
• In some cases, a pattern might be used to describe a problem (and
solution) associated with a complete process model (e.g., prototyping).
• In other situations, patterns can be used to describe a problem (and
solution) associated with a framework activity (e.g., planning) or an action
within a framework activity (e.g., project estimating).
39
• Pattern Name. The pattern is given a meaningful name describing it within
the context of the software process (e.g., TechnicalReviews).
• Forces. The environment in which the pattern is encountered and the issues
that make the problem visible and may affect its solution.
• Type. The pattern type is specified. suggests three types:
1. Stage pattern defines a problem associated with a framework activity for the
process.
• Since a framework activity encompasses multiple actions and work tasks, a
stage pattern incorporates multiple task patterns that are relevant to the stage
(framework activity).
• An example of a stage pattern might be Establishing Communication.
• This pattern would incorporate the task pattern Requirements Gathering and
others.
2. Task pattern defines a problem associated with a software engineering action
or work task and relevant to successful software engineering practice (e.g.,
Requirements Gathering is a task pattern).
3. Phase pattern define the sequence of framework activities that occurs
within the process, even when the overall flow of activities is iterative in
nature. 40
• An example of a phase pattern might be Spiral Model or Prototyping.
 2.2 Process Assessment and Improvement
• The existence of a software process is no guarantee that software will be
delivered on time, that it will meet the customer’s needs, or that it will
exhibit the technical characteristics that will lead to long-term quality
characteristics.
• Process patterns must be coupled with solid software engineering practice
• In addition, the process itself can be assessed to ensure that it meets a set
of basic process criteria that have been shown to be essential for a
successful software engineering.
• A number of different approaches to software process assessment and
improvement have been proposed over the past few decades.
1. Standard CMMI (Capability Maturity Model Integration) Assessment
Method for Process Improvement (SCAMPI)
• provides a five-step process assessment model that incorporates five
phases: initiating, diagnosing, establishing, acting, and learning.
• The SCAMPI method uses the SEI (Software Engineering Institute) CMMI
as the basis for assessment.

41
2. SPICE (ISO/IEC15504)
• a standard that defines a set of requirements for software process
assessment.
• The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy ( desired result) of any defined
software process.
3. ISO 9001:2000
• for Software a generic standard that applies to any organization that wants
to improve the overall quality of the products, systems, or services that it
provides.
• Therefore, the standard is directly applicable to software organizations and
companies.

42
 2.3 PRESCRIPTIVE PROCESS MODELS
• “Prescriptive” because they prescribe a set of process elements framework
activities, software engineering actions, tasks, work products, quality
assurance, and change control mechanisms for each project.
• Each process model also prescribes a process flow (also called a work
flow) that is, the manner in which the process elements are interrelated to
one another.
• Various models used in software development are
• Waterfall model
• V Model
• Incremental process models
• Evolutionary process models
• Prototyping
• The Spiral Model
• Concurrent Models
• Specialized process models.
• Component-Based Development
• The Formal Methods Model 43
 The Waterfall Model
• When the requirements for a problem are well understood, when work
flows from communication through deployment in a reasonably linear
fashion.
• for example an adaptation to accounting software that has been mandated
because of changes to government regulations
• The waterfall model, sometimes called the classic life cycle
• It suggests a systematic, sequential approach to software development that
begins with customer specification of requirements and progresses through
planning, modeling, construction, and deployment.

Figure: The waterfall model

44
• The waterfall model is the oldest paradigm for software engineering.
• However, over the past four decades, criticism of this process model has
caused even ardent supporters to question its efficacy.
• Among the problems that are sometimes encountered when the waterfall
model is applied are:
 Real projects rarely follow the sequential flow. Although the linear model
can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds.
 It is often difficult for the customer to state all requirements explicitly.
 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.
• Today, software work is fast paced and subject to a never-ending stream of
changes (to features, functions, and information content).
• The waterfall model is often inappropriate for such work.
• However, it can serve as a useful process model in situations where
requirements are fixed and work is to proceed to completion in a linear
manner.
45
• Advantages of Water fall Model
• Easy to Understand:
• Individual Processing:
• Properly Defined:
• Clear Milestones:
• Properly Documented:
• Reinforces Good Habits: The Classical Waterfall Model reinforces good habits like
define-before-design and design-before-code.
• Working: Classical Waterfall Model works well for smaller projects and projects
where requirements are well understood.
• Disadvantages
• No Feedback Path
• Difficult to accommodate Change Requests
• No Overlapping of Phases
• Limited Flexibility
• Limited Stakeholder Involvement
• Late Defect Detection
• Lengthy Development Cycle
• Not Suitable for Complex Projects
46
 V-model
• A variation in the representation of the waterfall model is called the V-
model.
• It provides quality assurance actions to the actions associated with
communication, modeling, and early construction activities.
• As a software team moves down the left side of the V, basic problem
requirements are refined into progressively more detailed and technical
representations of the problem and its solution.
• Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests (quality assurance actions) that
validate each of the models created as the team moves down the left side.
• In reality, there is no fundamental difference between the classic life cycle
and the V-model.
• The V-model provides a way of visualizing how verification and validation
actions are applied to earlier engineering work.

47
Figure : The V-model
48
 Incremental Process Models
• There are many situations in which initial software requirements are
reasonably well defined but the overall scope of the development is
excluded.
• In addition, there may be a compelling need to provide a limited set of
software functionality to users quickly and then refine and expand on that
functionality in later software releases.
• In such cases, you can choose a process model that is designed to produce
the software in increments.
• The incremental model combines the elements’ linear and parallel
process flows.
• The incremental model applies linear sequences in a staggered fashion as
calendar time progresses.
• Each linear sequence produces deliverable “increments” of the software.

49
Figure : The incremental model

50
• 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.
• The first increment is often a core product.
• That is, basic requirements are addressed but many supplementary
features (some known, others unknown) remain undelivered.
• The core product is used by the customer (or undergoes detailed
evaluation).
• As a result of use and/ or evaluation, a plan is developed for the next
increment.
• This process is repeated following the delivery of each increment, until the
complete product is produced.

51
Advantages of the Incremental Process Model
• Prepares the software fast.
• Clients have a clear idea of the project.
• Changes are easy to implement.
• Provides risk handling support, because of its iterations.
• Adjusting the criteria and scope is flexible and less costly.
• Comparing this model to others, it is less expensive.
• The identification of errors is simple.
Disadvantages of the Incremental Process Model
• A good team and proper planned execution are required.
• Because of its continuous iterations the cost increases.
• Issues may arise from the system design if all needs are not gathered
upfront throughout the program lifecycle.
• Every iteration step is distinct and does not flow into the next.
• It takes a lot of time and effort to fix an issue in one unit if it needs to be
corrected in all the units.
52
 Evolutionary Process Models
• Software, like all complex systems, evolves over a period of time.
• Business and product requirements often change as development
proceeds, making a straight line path to an end product unrealistic;
• Tight market deadlines make completion of a comprehensive software
product impossible, but a limited version must be introduced to meet
competitive or business pressure;
• A set of core product or system requirements is well understood, but the
details of product or system extensions have yet to be defined.
• In these and similar situations, you need a process model that has been
explicitly designed to accommodate a product that grows and changes.
• Evolutionary models are iterative.
• They are characterized in a manner that enables you to develop
increasingly more complete versions of the software.
• Two common evolutionary process models are Prototyping and Spiral
Model

53
Prototyping
• Often, a customer defines a set of general objectives for software, but does
not identify detailed requirements for functions and features.
• In other cases, the developer may be unsure of the efficiency of an
algorithm, the adaptability of an operating system, or the form that human-
machine interaction should take.
• In these, and many other situations, a prototyping paradigm may offer the
best approach.
• The prototyping paradigm assists you and other stakeholders to better
understand what is to be built when requirements are fuzzy.
• The prototyping paradigm begins with communication.
• You meet with other stakeholders to define the overall objectives for the
software, identify whatever requirements are known, and outline areas
where further definition is mandatory.
• A prototyping iteration is planned quickly, and modeling (in the form of a
“quick design”) occurs.

54
 Figure: The prototyping paradigm

• Ideally, the prototype serves as a mechanism for identifying software

requirements
• The prototype can serve as “the first system”
• Both stakeholders and software engineers like the prototyping paradigm.
• Users get a feel for the actual system, and developers get to build something
immediately.
55
• Advantages of Prototyping Model:
1. This model is flexible in design.
2. It is easy to detect errors.
3. We can find missing functionality easily.
4. There is scope of refinement, it means new requirements can be easily
accommodated.
5. It can be reused by the developer for more complicated projects in the
future.
6. It ensures a greater level of customer satisfaction and comfort.
7. It is ideal for online system.
8. It helps developers and users both understand the system better.
9. Integration requirements are very well understood and deployment
channels are decided at a very early stage.
10. It can actively involve users in the development phase.

56
• Disadvantages of using Prototype Model :
1. This model is costly.
2. It has poor documentation because of continuously changing customer
requirements.
3. There may be too much variation in requirements.
4. Customers sometimes demand the actual product to be delivered soon
after seeing an early prototype.
5. There may be sub-optimal solutions because of developers in a hurry to
build prototypes.
6. Customers may not be satisfied or interested in the product after seeing
the initial prototype.
7. There is certainty in determining the number of iterations.
8. There may be incomplete or inadequate problem analysis.
9. There may increase the complexity of the system.
• The key is to define the rules of the game at the beginning; that is, all
stakeholders should agree that the prototype is built to serve as a
mechanism for defining requirements.
• It is then discarded (at least in part), and the actual software is engineered
57
with an eye toward quality.
The Spiral Model
• The spiral model is an evolutionary software process model that couples the
iterative nature of prototyping with the controlled and systematic aspects of
the waterfall model.
• It provides the potential for rapid development of increasingly more
complete versions of the software.
• The spiral development model is a risk-driven process model
• It has two main distinguishing features.
• One is a cyclic approach for incrementally growing a system’s degree of
definition and implementation while decreasing its degree of risk.
• The other is a set of anchor point milestones for ensuring stakeholder
commitment to feasible and mutually satisfactory system solutions.
• Using the spiral model, software is developed in a series of evolutionary
releases.
• During early iterations, the release might be a model or prototype.
• During later iterations, increasingly more complete versions of the
engineered system are produced.
58
 Figure: A typical spiral model
• Unlike other process models that end when software is delivered, the spiral model can
be adapted to apply throughout the life of the computer software.
• The spiral model is a realistic approach to the development of large-scale systems and
software.
• Because software evolves as the process progresses, the developer and customer
better understand and react to risks at each evolutionary level

59
Advantages of the Spiral Model
• Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development model to
follow due to the risk analysis and risk handling at every phase.
• Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
• Flexibility in Requirements: Change requests in the Requirements at a later phase
can be incorporated accurately by using this model.
• Customer Satisfaction: Customers can see the development of the product at the
early phase of the software development and thus, they habituated with the system
by using it before completion of the total product.
• Iterative and Incremental Approach: The Spiral Model provides an iterative and
incremental approach to software development, allowing for flexibility and
adaptability in response to changing requirements or unexpected events.
• Emphasis on Risk Management: The Spiral Model places a strong emphasis on
risk management, which helps to minimize the impact of uncertainty and risk on
the software development process.
• Improved Communication: The Spiral Model provides for regular evaluations
and reviews, which can improve communication between the customer and the
development team.
• Improved Quality: The Spiral Model allows for multiple iterations of the software
60
development process, which can result in improved software quality and reliability.
Disadvantages of the Spiral Model

• Complex: The Spiral Model is much more complex than other SDLC models.
• Expensive: Spiral Model is not suitable for small projects as it is expensive.
• Too much dependability on Risk Analysis: The successful completion of the
project is very much dependent on Risk Analysis. Without very highly
experienced experts, it is going to be a failure to develop a project using this
model.
• Difficulty in time management: As the number of phases is unknown at the
start of the project, time estimation is very difficult.
• Complexity: The Spiral Model can be complex, as it involves multiple
iterations of the software development process.
• Time-Consuming: The Spiral Model can be time-consuming, as it requires
multiple evaluations and reviews.
• Resource Intensive: The Spiral Model can be resource-intensive, as it
requires a significant investment in planning, risk analysis, and evaluations.

61
 Concurrent Models
• The concurrent model is a methodology in which multiple phases of the
software development process are performed simultaneously
(concurrently).
• The main goal of the concurrent development model is to produce a final
product that meets the customer's requirements while minimizing the
overall development time and cost.
• In other words, it is a way to streamline the software development process
by simultaneously working on various aspects of the project.
• It involves all the Communaction design coding testing deployment

62
• Under Development: it involves
Requirement gathering, design and
coding
• Awaiting changes : if customer wants
any changes in requirement it is
gathered.
• Under revision : Do changes as per
customer requirement sent to under
review
• Under Review : Testing phase check
weather customer requirements are
matched or not?
• Baselined : Complete project as per SRS
document
• Done : Project is complete and deploy
to customer

63
Advantages of the concurrent development model
• This model is applicable to all types of software development processes.
• New features can be added late in the project
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent development model
• It needs better communication between the team members. This may not
be achieved all the time.
• It requires to remember the status of the different activities.
• SRS must be continually updated to reflect changes/

64
SPECIALIZED PROCESS MODELS
• Specialized process models take on many of the characteristics of one or
more of the traditional models discussed
• However, these models tend to be applied when a specialized or narrowly
defined software engineering approach is chosen.
• Component-Based Development
• It is a process that focuses on the design and development of computer-
based systems with the use of reusable software components.
• Component-based development (CBD) is a CBSE activity that occurs in
parallel with domain engineering.
• Using analysis and architectural design methods, the software team refines
an architectural style that is appropriate for the analysis model created for
the application to be built.
• Modeling and construction activities begin with the identification of
candidate components.
• These components can be designed as either conventional software
modules or object-oriented classes or packages of classes.

65
• Regardless of the technology that is used to create the components, the
component-based development model incorporates the following step
1. Available component-based products are researched and evaluated for the
application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.

• The component-based development model leads to software reuse, and

reusability provides software engineers with a number of measurable
benefits including a reduction in development cycle time and a reduction
in project cost if component reuse becomes part of your organization’s
culture

66
 The Formal Methods Model
• The formal methods model encompasses a set of activities that leads to
formal mathematical specification of computer software.
• Formal methods enable you to specify, develop, and verify a computer-
based system by applying a rigorous, mathematical notation.
• When formal methods are used during development, they provide a
mechanism for eliminating many of the problems that are difficult to
overcome using other software engineering paradigms.
• Although not a mainstream approach, the formal methods model offers
the promise of defect-free software.
• The development of formal models is currently quite time consuming and
expensive.
• Because few software developers have the necessary background to apply
formal methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for
technically unsophisticated customers.

67