Module-01

Introduction to Software Engineering

Process Models
 INTRODUCTION
Computer software is the product that software
professionals build and then support over the
long term. It encompasses programs that
execute within a computer of any size and
architecture.
Software engineering encompasses a process, a
collection of methods (practice) and an array
of tools that allow professionals to build high-
quality computer software.
 INTRODUCTION
Software engineers build and support software, and
virtually everyone in the industrialized world uses it
either directly or indirectly.
Software is important because it affects nearly every
aspect of our lives and has become pervasive in our
commerce, our culture, and our everyday activities.
Software engineering is important because it enables us
to build complex systems in a timely manner and with
high quality.
 Introduction
What are the steps to build software? 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 software engineering
approach.
What is the work product?

From the point of view of a software engineer, the work product is the set of
programs, content (data), and other work products that are computer software.

But from the user’s viewpoint, the work product is the resultant information that
somehow makes the user’s world better.
 1.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(process).
 As a product, it produces, manages and displays the information.
 i.e. it delivers the computing potential embodied by computer
hardware or more broadly, by a network of computers that are
accessible by local hardware.
 As the vehicle used to deliver the product, software acts as the
basis for the control of the computer (operating systems), the
communication of information (networks), and the creation and
control of other programs (software tools and environments).
Questions when modern computer based systems are built:

• Why does it take so long to get software finished?

• Why are development costs so high?
• Why can’t we find all errors before we give the software to
our customers?
• Why do we spend so much time and effort maintaining
existing programs?
• Why do we continue to have difficulty in measuring progress
as software is being developed and maintained?
 1a.DEFINING SOFTWARE
Software is:
1) instructions (computer programs) that when executed
provide desired features, function, and performance.
2) data structures that enable the programs to adequately
manipulate information, and
3) descriptive information in both hard copy and virtual
forms that describes the operation and use of the
programs.
 software characteristics diff.from h/w
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.
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 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.
 The hardware begins to wear out.
 software characteristics
• Software is not susceptible to the environmental
maladies that cause hardware to wear out.
• The failure rate curve for software should take the
form of the “idealized curve” .
• Undiscovered defects will cause high failure rates early
in the life of a program.
• software doesn’t wear out. But it does deteriorate!
• 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.
 software characteristics
3. Although the industry is moving toward component-
based construction, most software continues to be
custom built.
 A software component should be designed and implemented so
that it can be reused in many different programs.
 Modern reusable components encapsulate both data and the
processing that is applied to the data, enabling the software
engineer to create new applications from reusable parts.
 1b.Software Application Domain

Seven broad categories of computer software:

1.System software—a collection of programs written to service
other programs. Some system software (e.g., compilers,
editors, and file management utilities) processes complex, but
determinate, information structures.it provide services to
other pgms
2.Application software—stand-alone programs that solve a
specific business need. application software is used to control
business functions in real time.eg.C,JAVA. it provide services to
users.
 Software Application Domain
3.Engineering/scientific software—
 characterized by “number crunching” algorithms.
 Applications range from astronomy to volcanology,
 automotive stress analysis to space shuttle orbital dynamics,
 molecular biology to automated manufacturing. Eg.calculus
4.Product-line software—
 designed to provide a specific capability for use by many different customers.
 Product-line software can focus on a limited and esoteric marketplace (e.g.,
inventory control products) or
 address mass consumer markets (e.g., word processing, spreadsheets, computer
graphics, multimedia, entertainment, database management, and personal and
business financial applications).
 Software Application Domain
5.Embedded software-it lies in hardware of system and used for control
functions.
Eg.Microwave oven keypad controls. it provide services related to hardware.
6.Web applications—
 Called “WebApps” . it provide services to websites.
 This is network-centric software category spans a wide array of applications.
 In their simplest form, WebApps can be little more than a set of linked
hypertext files that present information using text and limited graphics.
7.Artificial intelligence software—
 Makes use of nonnumerical algorithms to solve complex problems that are
not amenable to computation or straight forward analysis.
 Applications within this area include robotics, expert systems, pattern
recognition (image and voice), artificial neural networks, theorem proving,
and game playing.
1c.Legacy software

• Very old software

Dayani-Fard and his colleagues describe legacy software in the following way:
 Legacy software systems were developed decades ago Have been
continually modified to meet changes in business requirements and
computing platforms.
 The proliferation(increase) of such systems is causing headaches for large
organizations who find them costly to maintain and risky to evolve.
Liu and his colleagues extend this description by noting that :
 “many legacy systems remain supportive to core business functions and
are ‘indispensable’ (necessary) to the business.”
 Hence, legacy software is characterized by longevity and business
criticality.
legacy software

Additional characteristic of legacy software:

• poor quality ,
• inextensible designs,
• convoluted code,
• poor or nonexistent documentation,
• test cases that were never archived,
• a poorly managed change history and result.
legacy systems often evolve for one or more of the following reasons:
• The software must be adapted to meet the needs of new computing environments or technology.
• The software must be enhanced(improve) to implement new business requirements.
• The software must be extended to make it interoperable with other more modern systems or
databases.
• The software must be re-architected to make it viable within a network environment.
 2.UNIQUE NATIURE OF WEBAPPS
 WebApps are one of a number of distinct software
categories.
 it can be argued that WebApps are different.
 Powell suggests that Web-based systems and
applications “involve a mixture between print
publishing and software development, between
marketing and computing, between internal
communications and external relations, and
between art and technology.”
Attributes of WebApps.

Network intensiveness. A WebApp resides on a network and

must serve the needs of a diverse community of clients.
Concurrency. A large number of users may access the WebApp at
onetime. In many cases, the patterns of usage among end
users will vary greatly.
Unpredictable load. The number of users of the WebApp may
vary by orders of magnitude from day to day. One hundred
users may show up on Monday; 10,000 may use the system on
Thursday.
 Attributes of WebApps.
Performance. If a WebApp user must wait too long (for access, for server
side processing, for client-side formatting and display), he or she may
decide to go elsewhere.
Availability :users of popular WebApps often demand access on a
24/7/365 basis.
Data driven: The primary function of many WebApps is to use hypermedia
to present text, graphics, audio, and video content to the end user. In
addition, WebApps are commonly used to access information that exists
on data-bases that are not an integral part of the Web-based
environment (e.g. commerce or financial applications).
Attributes of WebApps

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. Although immediacy—the compelling need to
get software to market quickly—is a characteristic of many
application domains, WebAppsoften exhibit a time-to-
market that can be a matter of a few days or weeks.
Attributes of WebApps.

Security. In order to protect sensitive content and provide secure

modes of data transmission, strong security measures must be
implemented throughout the infrastructure that supports a WebApp
and within the application itself.
Aesthetics. An undeniable part of the appeal of a WebApp is its look
and feel. When an application has been designed to market or sell
products or ideas, aesthetics may have as much to do with success as
technical design.
 3.Software Engineering
In order to build software that is ready to meet the challenges of
the twenty-first century, you must recognize a few simple
realities:
 Software has become deeply embedded in virtually every aspect of
our lives, and as a consequence, the number of people who have an
interest in the features and functions provided by a specific
application has grown dramatically.
 Software Engineering
 The information technology requirements demanded by
individuals, businesses, and governments grow increasing
complex with each passing year. Large teams of people now
create computer programs that were once built by a single
individual.
 Individuals, businesses, and governments increasingly rely on
software for strategic and tactical decision making as well as day-
to-day operations and control.
 As the perceived value of a specific application grows, the
likelihood is that its user base and longevity will also grow.
These simple realities lead to one conclusion: software in all of its
forms and across all of its application domains should be engineered.
 Software Engineering
A definition proposed by Fritz Bauer
Software engineering is the establishment and use of sound
engineering principles in order to obtain economically
software that is reliable and works efficiently on real machines.
Software Engineering(IEEE): The application of a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance of software that is, the application
of engineering to software.
 Software Engineering
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.
The software engineering process is the glue that holds the
technology layers together and enables rational and timely
development of computer software.
 Software Engineering
 Software Methods encompass a broad array of tasks that
include communication, requirements analysis, design
modeling, program construction, testing, and sup-port. All
technical how to’s (how to test,how to write modules etc.)will
come under this.
 Software engineering tools provide automated or semi
automated support for the process and the methods.
 4.Software Process
 A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.
• As 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.
• As an action (e.g., architectural design) encompasses a set of
tasks that produce a major work product (e.g., an architectural
design model).
• As a task, it focuses on a small, but well-defined objective (e.g.,
conducting a unit test) that produces a tangible outcome.
 Software Process
A process framework establishes the foundation for a complete
software engineering process by identifying a small number of
framework activities that are applicable to all software
projects, regardless of their size or complexity.
A generic process framework for software engineering
encompasses five activities:
Communication. Before any technical work can commence, it is
critically important to communicate and collaborate with the
customer. The intent is to understand stakeholders’ objectives
for the project and to gather requirements that help define
software features and functions.
 Software Process
Planning. Any complicated journey can be simplified if a map
exists. A software project is a complicated journey, and the
planning activity creates a “map” that helps guide the team as
it makes the journey. The map called software project plan .
Modeling. A software engineer creating models to better
understand software requirements and the design that will
achieve those requirements.
Construction. This activity combines code generation (either
manual or automated) and the testing that is required to
uncover errors in the code.
Deployment. The software is delivered to the customer who
evaluates the delivered product and provides feedback based
on the evaluation.
 Umbrella Activities
Software engineering process framework activities are complemented by a
number of umbrella activities. In general, umbrella activities are applied
throughout a software project and help a software team manage and control
progress, quality, change, and risk. Typical umbrella activities(8) include(to
track, control & manage the project):
Software project tracking and control—allows the software team to assess
progress against the project plan and take any necessary action to maintain
the schedule.
Risk management—assesses risks that may affect the outcome of the project
or the quality of the product.
Software quality assurance—defines and conducts the activities required to
ensure software quality.
Technical reviews—assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the next activity.
 Umbrella Activities
Measurement—defines and collects process, project, and product
measures that assist the team in delivering software that meets
stakeholders’ needs; can be used in conjunction with all other
framework and umbrella activities.(cost,time,manpower)
Software configuration management—manages the effects of change
throughout the software process.
Reusability management—defines criteria for work product
reuse(including software components) and establishes mechanisms
to achieve reusable components.
Work product preparation and production—encompasses the activities
required to create work products such as models, documents, logs,
forms, and lists.
 5.Software Engineering Practice

communication, planning, modeling, construction, and

deployment—and umbrella activities establish a skeleton
architecture for software engineering work.
Generic concepts and principles that apply to framework
activities:
1.The Essence of Practice: outlined by GeorgePolya
a. Understand the problem (communication and analysis).
b. Plan a solution (modeling and software design).
c. Carry out the plan (code generation).
d. Examine the result for accuracy (testing and quality
assurance).
 Software Engineering Practice

a.Understand the problem.

• who are the stake-holders?
• What are the unknowns? What data, functions, and
features are required to properly solve the problem?
• Can the problem be compartmentalized? Is it
possible to represent smaller
• problems that may be easier to understand?
• Can the problem be represented graphically? Can an
analysis model be created?
 Software Engineering Practice

b.Plan the solution.

• Have you seen similar problems before? Are there
patterns that are recognizable in a potential solution?
• Has a similar problem been solved? If so, are elements
of the solution reusable?
• Can sub problems be defined? If so, are solutions
readily apparent for the sub problems?
• Can you represent a solution in a manner that leads to
effective implementation? Can a design model be
created?
 Software Engineering Practice

c.Carry out the plan

• Does the solution conform(comply with rules) to the
plan? Is source code traceable to the design model?
• Is each component part of the solution provably
correct? Have the design and code been reviewed, or
better, have correctness proofs been applied to the
algorithm?
 Software Engineering Practice

d.Examine the result.

• Is it possible to test each component part of
the solution? Has a reasonable testing strategy
been implemented?
• Does the solution produce results that
conform to the data, functions, and features
that are required? Has the software been
validated against all stakeholder requirements?
 Software Engineering Practice

2.GeneralPrinciples
David Hooker [Hoo96] has proposed seven principles that
focus on software engineering practice as a whole.
The First Principle: The Reason It All Exists
A software system exists for one reason: to provide value to
its users. All decisions should be made with this in mind.
The Second Principle: KISS (Keep It Simple, Stupid!)
Software design is not a haphazard(without a plan) process.
There are many factors to consider in any design effort.
All design should be as simple as possible, but no simpler.
 Software Engineering Practice

The Third Principle: Maintain the Vision

A clear vision is essential to the success of a software
project. Having an empowered architect who can hold the
vision and enforce compliance helps ensure a very
successful software project.
The Fourth Principle: What You Produce, Others Will Consume
Someone may have to debug the code you write, and
that makes them a user of your code. Making their
job easier adds value to the system.
 Software Engineering Practice

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. systems must be
ready to adapt to these and other changes.
The Sixth Principle: Plan Ahead for Reuse
Reuse saves time and effort. Achieving a high level of reuse is the hardest goal
to accomplish in developing a software system. The reuse of code and
designs has been proclaimed as a major benefit of using object-oriented
technologies.
The Seventh principle: Think!
Placing clear, complete thought before action almost always produces better
results.
 6.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.
Management myths.
Myth: We already have a book that’s full of standards and
procedures for building software. Won’t that provide my
people with everything they need to know?
Reality: no(is that book correct, complete, adapt to new
technologies)
 Software Myths
Myth: If we get behind schedule, we can add more
programmers and catch up(sometimes called the
“Mongolian horde” concept)
Reality: People can be added but only in a planned and
well coordinated manner.(if they don’t now anything,
train them)
Myth: If I decide to outsource the software project to a
third party, I can just relax and let that firm build it.
Reality: If an organization does not understand how to
manage and control(need to follow up).
 Software Myths
Customer myths:
In many cases, the customer believes myths about software because
software managers and practitioners do little to correct
misinformation.
Myth: A general statement of objectives is sufficient to begin writing
programs—we can fill in the details later.
Reality: only through effective and continuous communication between
customer and developer.
Myth: Software requirements continually change, but change can
be easily accommodated because software is flexible.
Reality: change can cause upheaval that requires additional
resources and major design modification.(cost)
 Software Myths
Practitioner’s myths
Myth: Once we write the program and get it to work, our job is
done.
Reality: the sooner you begin ‘writing code,’ the longer it’ll take
you to get done.
Myth: Until I get the program “running” I have no way of
assessing its quality.
Reality: Software reviews are a “quality filter” that have been
found to be more effective than testing for finding certain
classes of software defects.
 Software Myths
Myth: The only deliverable work product for a
successful project is the working program.
Reality: A working program is only one part of a
software configuration that includes many elements.
(give description about project,catalog)
Myth: Software engineering will make us create
voluminous and unnecessary documentation and will
invariably slow us down.
Reality: Software engineering is not about creating
documents. It is about creating a quality product.