Software Engineering

Subject Code:BCASP501
What is Software?

➢ Collection of computer programs, procedures,

rules, associated document and data.

➢ Software = Program+Documentation+Operating
Procedures.
 Software Characteristics:
➢ Software is a logical rather than a physical system element.
Therefore, software has characteristics that are considerably
different than those of hardware:

1. Software is developed or engineered, it is not manufactured:

Although some similarities exist between software

development and hardware manufacture, 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.
2. Software doesn't "wear out."
➢ 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, 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.
 Fig: Failure curve for hardware

Fig: Idealized and actual failure curves for software

3.Reusability of components
➢ Components (e.g. Subsystems or single objects ) of one
application reused in another application.

Benefits:
➢ Increased reliability( components already exercised in
working systems)
➢ Accelerated development
➢ Speed up delivering
➢ Reduced cost
 Software Applications
The following software areas indicate the breadth
of potential applications:
➢ System software.
System software is a collection of programs written to
service other programs e.g. compilers.
➢ Business software.
Business information processing is the largest single
software application area. Discrete "systems" (e.g., payroll,
accounts receivable/payable, inventory)have evolved into
management information system (MIS) software that
accesses one or more large databases containing business
information.
➢ Personal computer software.
The personal computer software market has increased
rapidly over the past two decades. Word processing,
spreadsheets, computer graphics, multimedia,
entertainment, database management, personal and
business financial applications and database access are only
a few of hundreds of applications.
➢ Embedded software.
Embedded software resides in ROM and is used to control
products and systems for the consumer and industrial
markets. Embedded software can perform very limited
functions (e.g., keypad control for a microwave oven) or
provide significant function and control capability (e.g.,
digital functions in an automobile such as fuel control,
dashboard displays, and braking systems).
➢ Artificial Intelligence software.
Expert systems, also called knowledgebase systems, pattern
recognition (image and voice), artificial neural networks are
representative of applications within this category.
 Software Process
➢ When you 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.
➢ A framework for the tasks that are required to build high-
quality software.
➢ Methods of developing software.
 SOFTWARE PROCESS MODELS

➢ A software life cycle is the series of identifiable stages that a

software product undergoes during its lifetime.
➢ Common stages are: Feasibility study, requirements analysis,
design, coding, testing and maintenance.
➢ Each of these stages is called life cycle phase.
➢ A software life cycle model is often referred to as software
process model.
CLASSICAL WATERFALL MODEL OR THE LINEAR
SEQUENTIAL MODEL
Waterfall Model
Activities in each phase of the life cycle
Activities undertaken during feasibility study:
Activities undertaken during feasibility study: -
 Requirements Analysis
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, and
➢ 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 customer requirements identified during the
requirements gathering and analysis activity are organized
into a SRS document.
Activities undertaken during 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.
Activities undertaken during coding and unit testing:

The purpose of the coding and unit testing 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.
 Activities undertaken during 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

➢ 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.
Activities undertaken during maintenance:
➢ Maintenance of a typical software product requires much more
than the effort necessary to develop the product itself.
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.
Software Project Management
 Introduction
➢Many software projects fail:
Due to faulty project management
practices
➢Goal of software project management:
 Enable a group of engineers to work efficiently
towards successful completion of a software
project.
Responsibility of project managers
➢ Software project managers take the overall responsibility
of steering a project to success. It is very difficult to
objectively describe the job responsibilities of a project
manager. The job responsibility of a project manager
ranges from invisible activities like building up team
morale to highly visible customer presentations.
➢ Most managers take responsibility for:
▪ Project proposal writing,
▪ Project cost estimation,
▪ Scheduling,
▪ Project staffing,
▪ Project monitoring and control,
▪ Software configuration management,
▪ Risk management,
▪ Managerial report writing and presentations, etc.
Introduction (continued…):
➢ A project manager’s activities can be broadly classified
into:
1. project planning,
2. project monitoring and control activities.
➢ The project planning activity is undertaken before the
development starts to plan the activities to be undertaken
during development. The project monitoring and control
activities are undertaken once the development activities start
with the aim of ensuring that the development proceeds as per
plan and changing the plan whenever required to cope up with
the situation.
Project planning
➢ Once a project is found to be feasible, software project managers
undertake project planning. Project planning is undertaken and
completed even before any development activity starts. Project
planning consists of the following essential activities:
➢ Estimating the following attributes of the project:
 Project size: What will be the size of the product?
 Cost: How much will it cost to develop the project?
 Duration: How long will it take to complete the development?
 Effort: How much effort would be required?
The effectiveness of the subsequent planning activities is based on the
accuracy of these estimations.
➢ Scheduling manpower and other resources
➢ Staff organization and staffing plans
➢ Risk identification, analysis, and abatement planning
➢ Miscellaneous plans such as quality assurance plan, configuration
management plan, etc.
Precedence ordering among planning
activities
Effort Estimation Cost
Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling
Metrics for software project size estimation
➢ Accurate estimation of the problem size is fundamental to
satisfactory estimation of effort, time duration and cost of a
software project. In order to be able to accurately estimate the
project size, some important metrics should be defined in
terms of which the project size can be expressed. The size of a
problem is obviously not the number of bytes that the source
code occupies. It is neither the byte size of the executable
code. The project size is a measure of the problem complexity
in terms of the effort and time required to develop the product.
➢ Currently two metrics are popularly being used widely to
estimate size:
 Lines of code (LOC) and
 Function Point (FP).
➢ The usage of each of these metrics in project size estimation
has its own advantages and disadvantages.
Lines of Code (LOC)
➢ LOC is the simplest among all metrics available to estimate project
size.
➢ This metric is very popular because it is the simplest to use. Using
this metric, the project size is estimated by counting the number of
source instructions in the developed program.
➢ Lines used for commenting the code and the header lines should be
ignored.
➢ Accurate estimation of the LOC count at the beginning of a project
is very difficult. In order to estimate the LOC count at the
beginning of a project, project managers usually divide the
problem into modules, and each module into sub modules and so
on, until the sizes of the different leaf-level modules can be
approximately predicted.
➢ Past experience in developing similar products is helpful. By using
the estimation of the lowest level modules, project managers arrive
at the total size estimation.
Shortcomings of LOC
➢ LOC gives a numerical value of problem size that can vary
widely with individual coding style – different programmers
lay out their code in different ways.
For example,
 One programmer might write several source instructions on a
single line whereas, another might split a single instruction
across several lines.
 This problem can be easily overcome by counting the
language tokens in the program rather than the lines of code.
 For the same problem, different programmers might come up
with programs having different LOC counts.
 This situation does not improve even if language tokens are
counted instead of lines of code.
Shortcomings of LOC (contd..)
➢ A good problem size measure should consider the overall
complexity of the problem and the effort needed to solve it.
➢ That is, it should consider the local effort needed to specify,
design, code, test, etc. and not just the coding effort.
➢ Coding is only a small part of the overall software
development activities.
➢ It is also wrong to argue that the overall product development
effort is proportional to the effort required in writing the
program code.
➢ This is because even though the design might be very
complex, the code might be straightforward and vice versa. In
such cases, code size is a grossly improper indicator of the
problem size.
Shortcomings of LOC (contd..)
➢ LOC measure correlates poorly with the quality and
efficiency of the code.
➢ Larger code size does not necessarily imply better quality or
higher efficiency.
➢ Some programmers produce lengthy and complicated code as
they do not make effective use of the available instruction set.
➢ In fact, it is very likely that a poor and sloppily written piece
of code might have larger number of source instructions than
a piece that is neat and efficient.
Shortcomings of LOC (contd..)
➢ It is very difficult to accurately estimate LOC in the final
product from the problem specification.
➢ The LOC count can be accurately computed only after the
code has been fully developed.
➢ Therefore, the LOC metric is little use to the project
managers during project planning.
➢ Since project planning is carried out even before any
development activity has started.
➢ This possibly is the biggest shortcoming of the LOC metric
from the project manager’s perspective.
 Function point (FP)
 Function point metric was proposed by Albrecht [1983]. This
metric overcomes many of the shortcomings of the LOC
metric.
 One of the important advantages of using the function point
metric is that it can be used to easily estimate the size of a
software product directly from the problem specification.
 This is in contrast to the LOC metric, where the size can be
accurately determined only after the product has fully been
developed.
Function point (FP)
 The conceptual idea behind the function point metric is that the size
of a software product is directly dependent on the number of
different functions or features it supports.
 A software product supporting many features would certainly be of
larger size than a product with less number of features. Each
function when invoked reads some input data and transforms it to
the corresponding output data.
 For example, the issue book feature (as shown in fig.) of a Library
Automation Software takes the name of the book as input and
displays its location and the number of copies available. Thus, a
computation of the number of input and the output data values to a
system gives some indication of the number of functions supported
by the system. Albrecht postulated that in addition to the number of
basic functions that a software performs, the size is also dependent
on the number of files and the number of interfaces.
 Function point is computed in two steps. The first step is to
compute the Unadjusted Function Point (UFP).
 UFP = (Number of inputs)*4 + (Number of outputs)*5 +(Number
of inquiries)*4 + (Number of files)*10 + (Number of
interfaces)*10

 Technical Complexity Factor (TCF) is computed as

 TCF=0.6 + (TF/100), where, TF=Technical Factor
 FP=UFP*TCF
 Number of inputs:
 Each data item input by the user is counted. A
group of related inputs are considered as a single
input.
 For example, while entering the data concerning
an employee to an employee pay roll software;
the data items name, age, sex, address, phone
number, etc. are together considered as a single
input. All these data items can be considered to be
related, since they pertain to a single employee.
 Number of outputs:
 The outputs considered refer to reports printed, screen
outputs, error messages produced, etc. A set of related data
items is counted as one output.
 Number of inquiries:

Each user query type is counted.

 Number of files:
 Each logical file is counted. A logical file means
groups of logically related data. Thus, logical files can
be data structures or physical files.
 Number of interfaces:
 Here the interfaces considered are the interfaces
used to exchange information with other systems.
 Examples of such interfaces is communication links
with other systems.
Feature point metric
 A major shortcoming of the function point measure is that it does not
take into account the algorithmic complexity of a software.
 That is, the function point metric implicitly assumes that the effort
required to design and develop any two functionalities of the system is
the same.
 But, we know that this is normally not true, the effort required to develop
any two functionalities may vary widely.
 It only takes the number of functions that the system supports into
consideration without distinguishing the difficulty level of developing
the various functionalities.
 To overcome this problem, an extension of the function point metric
called feature point metric is proposed.
 Feature point metric incorporates an extra parameter algorithm
complexity.
 This parameter ensures that the computed size using the feature point
metric reflects the fact that the more is the complexity of a function, the
greater is the effort required to develop it and therefore its size should be
larger compared to simpler functions.
Project Estimation techniques
 Estimation of various project parameters is a basic project
planning activity.
 The important project parameters that are estimated
include: project size, effort required to develop the
software, project duration, and cost.
 These estimates not only help in quoting the project cost to
the customer, but are also useful in resource planning and
scheduling.
 There are three broad categories ofestimation techniques:
1. Empirical estimation techniques
2. Heuristic techniques
3. Analytical estimation techniques
Empirical Estimation Techniques
 Empirical estimation techniques are based on making an
educated guess of the project parameters.
 While using this technique, prior experience with development
of similar products is helpful.
 Two popular empirical estimation techniques are:
1. Expert judgment technique and
2. Delphi cost estimation.
Expert Judgment Technique:
 Expert judgment is one of the most widely used estimation
techniques. In this approach, an expert makes an educated
guess of the problem size after analyzing the problem
thoroughly. Experts divide a software product into component
units and Add up the guesses for each of the components to
arrive at the overall estimate.
 Suffer from human errors and individual bias
Delphi cost estimation
 Delphi cost estimation approach tries to overcome some of the shortcomings of the
expert judgment approach.
 Delphi estimation is carried out by a team comprising of a group of experts and a
coordinator.
 In this approach, the coordinator provides each estimator with a copy of the
software requirements specification (SRS) document and a form for recording his
cost estimate.
 Estimators complete their individual estimates anonymously and submit to the
coordinator.
 In their estimates, the estimators mention any unusual characteristic of the product
which has influenced his estimation.
 The coordinator prepares and distributes the summary of the responses of all the
estimators, and includes any unusual rationale noted by any of the estimators.
Based on this summary, the estimators re-estimate. This process is iterated for
several rounds.
 However, no discussion among the estimators is allowed during the entire
estimation process.
 The idea behind this is that if any discussion is allowed among the estimators, then
many estimators may easily get influenced by the rationale of an estimator who
may be more experienced or senior.
 After the completion of several iterations of estimations, the coordinator takes the
responsibility of compiling the results and preparing the final estimate.