Software Engineering

Mrs Amandeep Kaur

Assistant Professor
Gujarat University
 Computer Software
Software is a set of instructions, data or programs that tells a computer what

to do and how to do it.

Computer software is a work product that software professionals build and

then support over many years.

These work products include programs that execute within computers 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.
 Importance Of Software

To interact with hardware

To perform tasks

To provide user interface

To manage data

To run applications

 Software Myths
 Management myths: Managers with software responsibility, like managers in most

disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and
improve quality. Like a drowning person who grasps at a straw, a software manager often
grasps at belief in a software myth, if that belief will lessen the pressure (even temporarily).

 Customer myths: A customer who requests computer software may be a person at the next

desk, a technical group down the hall, the marketing/sales department, or an outside
company that has requested software under contract. In many cases, the customer believes
myths about software because software managers and practitioners do little to correct
misinformation. Myths lead to false expectations (by the customer) and, ultimately,
dissatisfaction with the developer.

 Practitioner’s myths: Myths that are still believed by software practitioners have been

fostered by over 50 years of programming culture. During the early days, programming was
viewed as an art form. Old ways and attitudes die hard.
 Management Myths

 Myth: We already have a book that’s full of standards and procedures for building

software. Won’t that provide my people with everything they need to know?

 Reality: The book of standards may very well exist, but is it used? Are software

practitioners aware of its existence? Does it reflect modern software engineering

practice? Is it complete? Is it adaptable? Is it streamlined to improve time-to-
delivery while still maintaining a focus on quality? In many cases, the answer to all
of these questions is “no.”
 Management Myths…

 Myth: If we get behind schedule, we can add more programmers and catch up

(sometimes called the “Mongolian horde” concept).

 Reality: Software development is not a mechanistic process like manufacturing. In

the words of Brooks [Bro95]: “adding people to a late software project makes it
later.” At first, this statement may seem counterintuitive. However, as new people
are added, people who were working must spend time educating the newcomers,
thereby reducing the amount of time spent on productive development effort.
People can be added but only in a planned and well coordinated manner.
 Management Myths…

 Myth: If I decide to outsource the software project to a third party, I can just relax

and let that firm build it.

 Reality: If an organization does not understand how to manage and control

software projects internally, it will invariably struggle when it outsources software

projects.
 Customer Myths
 Myth: A general statement of objectives is sufficient to begin writing programs—
we can fill in the details later.
 Reality: Although a comprehensive and stable statement of requirements is not
always possible, an ambiguous “statement of objectives” is a recipe for disaster.
Unambiguous requirements (usually derived iteratively) are developed 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: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. When requirements changes are
requested early (before design or code has been started), the cost impact is
relatively small. However, as time passes, the cost impact grows rapidly—resources
have been committed, a design framework has been established, and change can
cause upheaval that requires additional resources and major design modification.
 Practitioner’s Myths
 Myth: Once we write the program and get it to work, our job is done.
 Reality: Someone once said that “the sooner you begin ‘writing code,’ the longer it’ll take
you to get done.” Industry data indicate that between 60 and 80 percent of all effort
expended on software will be expended after it is delivered to the customer for the first
time.
 Myth: Until I get the program “running” I have no way of assessing its quality.
 Reality: One of the most effective software quality assurance mechanisms can be applied
from the inception of a project—the technical review. Software reviews are a “quality filter”
that have been found to be more effective than testing for finding certain classes of software
defects.
 Myth: The only deliverable work product for a successful project is the working program.
 Reality: A working program is only one part of a software configuration that includes many
elements. A variety of work products (e.g., models, documents, plans) provide a foundation
for successful engineering and, more important, guidance for software support.
 Myth:Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
 Reality: Software engineering is not about creating documents. It is about creating a quality
product. Better quality leads to reduced rework. And reduced rework results in faster
delivery times.
 Paradigm
Software paradigm is a theoretical framework that serves as a guide for the
development and structure of a software system.
There are several software paradigms, including:
Imperative paradigm
Object-oriented paradigm
Functional paradigm
Logic paradigm
Imperative paradigm: This is the most common paradigm and is based on the

idea that a program is a set of instructions that tell a computer what to do. It is often
used in languages such as C and C++.

Object-oriented paradigm: This paradigm is based on the idea of objects, which

are self-contained units that contain both data and behavior. It is often used in
languages such as Java, C#, and Python.

Functional paradigm: This paradigm is based on the idea that a program is a set

of mathematical functions that transform inputs into outputs. It is often used in

languages such as Haskell, Lisp, and ML.

Logic paradigm: This paradigm is based on the idea that a program is a set of

logical statements that can be used to infer new information. It is often used in
languages such as Prolog and Mercury.
 Generic view
 A set of activities, methods, practices, and transformations that people use to develop and

maintain software and the associated products (e.g., project plans, design documents, code,
test cases, and user manuals)

Software Engineering - A Layered Technology

 Software engineering encompasses a process, the management of activities, technical

methods, and use of tools to develop software products.

 The foundation for software engineering is the process layer. It is the glue that holds the

technology layers together and enables rational and timely development of computer
software.

 Process defines a framework that must be established for effective delivery of software

engineering technology.
 Generic view…
 The software process forms the basis for management control of software projects and establishes

the context in which technical methods are applied, work products (models, documents, data,

reports, etc.) are produced, milestones are established, quality is ensured, and change is properly

managed.

 Software engineering methods provide the technical ―how to’s for building software. Methods

encompass a broad array of tasks that include communication, req. analysis, design, coding,

testing and support.

 Software engineering tools provide automated or semi-automated support for the process and the

methods.

 When tools are integrated so that info. Created by one tool can be used by another, a system for

the support of software development called computer-aided software engineering is established

 Generic view…
A PROCESS FRAMEWORK

Establishes the foundation for a complete software process

Identifies a number of framework activities applicable to all software projects

Also include a set of umbrella activities that are applicable across the entire

software process.

Used as a basis for the description of process models

Generic process activities:

1) Communication. 2) Planning. 3) Modeling. 4) Construction. 5) Deployment

 Software Crisis
Software Crisis is a term used in computer science for the difficulty of writing

useful and efficient computer programs in the required time.

The term software crisis revolves around three concepts: complexity, change and the

expectations.

This term was given by F. L. Bauer at the first NATO Software Engineering

Conference in 1968 at Garmisch, Germany.

In general it refers to poorly written, hard to read, error-prone software that often

lacks good documentation.

Software crisis is also referred to the inability to hire enough qualified programmers.
 Software Crisis…
The most visible symptoms of the software crisis are late delivery, over budget;

Product does not meet specified requirements, inadequate documentation.

Increasing Increasing Increasing

Demand Complexity Challenges

Software Crisis

Same Same Same

Workflow Methods Tools
 Causes Of Software Crisis…
 The cost of owning and maintaining software was as expensive as developing the
software.
 At that time Projects were running overtime.
 At that time Software was very inefficient.
 The quality of the software was low quality.
 Software often did not meet user requirements.
 The average software project overshoots its schedule by half.
 At that time Software was never delivered.
 Non-optimal resource utilization.
 Challenging to alter, debug, and enhance.
 The software complexity is harder to change.
 Solution Of Software Crisis
There is no single solution to the crisis. One possible solution to a software
crisis is Software Engineering because software engineering is a systematic,
disciplined, and quantifiable approach. For preventing software crises, there
are some guidelines:

Reduction in software over budget.

The quality of the software must be high.

Less time is needed for a software project.

Experienced and skilled people working on the software project.

Software must be delivered.

Software must meet user requirements.

 Software Processes
A software process is the set of activities and associated outcome that produce a
software product. Software engineers mostly carry out these activities. These are four
key process activities, which are common to all software processes. These activities
are:

1) Software specifications: The functionality of the software and constraints on its

operation must be defined.

2) Software development: The software to meet the requirement must be

produced.

3) Software validation: The software must be validated to ensure that it does what
the customer wants.

4) Software evolution: The software must evolve to meet changing client needs.
 Software life cycle model

It is well-defined, structured sequence of stages in software engineering to develop the

intended software product.

The period of time that starts when a software product is conceived and ends when the
product is no longer available for use.

SDLC provides a series of steps to be followed to design and develop a software product
efficiently.
SDLC Steps
Waterfall Model
 Waterfall Model Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost or
schedule
 Waterfall Model Deficiencies
 All requirements must be known upfront
 Deliverables created for each phase are considered frozen – inhibits
flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software development –
iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the system (until it may be
too late)
 When To Use Waterfall Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
Prototyping Model
 Advantages of Prototyping Model
 It allows the development team to quickly create a working model of the product,
which can be tested and evaluated by the users.
 It enables the development team to gather feedback from the users, which can be
used to improve the design and functionality of the final product.
 It allows the development team to focus on specific aspects of the product, rather than
trying to build the entire product at once.
 It allows for a more flexible and iterative development process, as the prototype can
be modified and improved based on the findings from each iteration.
 It can help to reduce the overall cost of the project, as the prototype can be developed
and tested with minimal resources.
 Disadvantages of Prototyping Model
 It may not be suitable for large and complex projects, as the prototype may not scale
well and may require a significant amount of rework to turn it into the final product.
 It can be time-consuming and costly to create multiple prototypes and revise them
based on user feedback.
 The prototype may not accurately represent the final product, leading to
misunderstandings and unrealistic expectations from users.
 The prototype may not adequately address all functional and non-functional
requirements of the final product.
 There is a risk of the prototype being discarded or significantly revised during the
development process, leading to wasted effort and resources.
 It can be difficult to accurately estimate the cost and timeline for a project using the
prototype model, as the scope may change significantly during the development
process.
 When To Use Prototyping Model
 Prototype model should be used when the desired system needs to have a lot of
interaction with the end users.
 Typically, online systems, web interfaces have a very high amount of interaction with
end users, are best suited for Prototype model. It might take a while for a system to be
built that allows ease of use and needs minimal training for the end user.
 Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.
Spiral Model
 Advantages 0f Spiral Model

 High amount of risk analysis hence, avoidance of Risk is enhanced.

 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
 Disadvantages Of Spiral Model

 Can be a costly model to use.

 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.
 When To Use Spiral Model
 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because of potential changes to
economic priorities
 Users are unsure of their needs
 Requirements are complex
 Significant changes are expected (research and exploration)
Evolutionary Model
 Advantages of Evolutionary Model
 Users get a chance to experiment with a partially developed system much before the full
working version is released.
 It is best suited to find the user requirements, the exact user requirements, and once it is
delivered to the customer, the software meets the customer requirements.
 Core modules get tested thoroughly, which reduces the chances of errors in the final delivery
software.
 Better management of complexity by developing one increment at a time.
 Better management of changing requirements
 Can get customer feedback and incorporate them much more efficiently than customer
feedback comes only after the development work is complete.
 Training can start on an earlier release, so customer feedback is taken into account.
 Frequent releases allow developers to fix unanticipated problems quicker.
 These releases are tested each time before deploying at the customer site. Therefore, it is less
likely to contain bugs.
 Disadvantages of Evolutionary Model

 The process is intangible – no regular, well-defined deliverables

 The process is unpredictable and hard to manage. E.g., scheduling, workforce
allocation, etc.
 Systems are rather poorly structured; continual, unpredictable changes tend to
degrade the software structure.
 Systems may not even converge to a final version.