Software Engg & Case Tools

PGIT104
Module I
Introduction to Software Engineering
 What is Software Engineering?
• Software: It is a program or a set of program
containing instructions that performs desired
functionality.
• It also comprises of data structures that
enables the program to manipulate
instructions.
• Engineering- The process of designing or
building something that serves for a particular
purpose.
• Software engineering is the application of
principles used in the field of engineering,
which usually deals with physical systems, to
the design, development, testing, deployment
and management of software systems.
• It is basically a systematic approach to the
design, development, testing and
maintainance of software systems.
 Dual Role of a software
1. As a Product-
– Transforms information - produces, manages,
acquires, modifies, displays, or transmits information
– Delivers computing potential of hardware and
networks
2. As a vehicle for delivering a product
– Controls other programs (operating system)
– Effects communications (networking software)
– Helps build other software (software tools &
environments)
 Why is software Engineering important?

• Enables to build complex system in timely

manner.
• Ensures high quality of software.
• Imposes discipline to work that can become
quite chaotic.
 What is work product?
1. Software engineer- the set of programs,
data along with documentation that is a part
of software.
2. User/customer- the functionality that is
delivered by the software that improves user
experience.
What does software engineering focus on?

1. Quality
2. Maintainability
Software engineering-A layered technology
• A software engg. Comprises of a process, a set of
methods for managing and developing the software
and a collection of tools.
• The bedrock that supports S/W engg. Is quality focus.
Software engineering-A layered technology

1. A quality Process
• Any engineering approach must rest on an quality.
• The "Bed Rock" that supports software Engineering is Quality
Focus.

2. Process
• Foundation for SE is the Process Layer
• SE process is the glue that holds all the technology layers
together and enables the timely development of computer
software.
• It forms the base for management control of software project.
Software engineering-A layered technology

3. Methods
• SE methods provide the "Technical Questions" for building
Software.
• Methods contain a broad array of tasks that include
communication requirement analysis, design modeling,
program construction testing and support.

4. Tools
• SE tools provide automated or semi-automated support for
the "Process" and the "Methods".
• Tools are integrated so that information created by one tool
can be used by another.
Software Life Cycle Models (SDLC)
• A software development life cycle (SDLC) model is a
conceptual framework describing all activities in a software
development project from planning to maintenance.
 Requirement Phase

• Requirement gathering and analysis is the most

important phase in software development lifecycle.
• Business Analyst collects the requirement from the
Customer/Client as per the clients business needs and
documents the requirements in the Business
Requirement Specification (BRS) (document name
varies depends upon the Organization. Some examples
are Customer Requirement Specification (CRS),
Business Specification (BS) etc., and provides the same
to Development Team.
 Analysis Phase

• Once the requirement gathering and analysis is done

the next step is to define and document the product
requirements and get them approved by the customer.
This is done through SRS (Software Requirement
Specification) document. 
• SRS consists of all the product requirements to be
designed and developed during the project life cycle.
• Key people involved in this phase are Project
Manager, Business Analysist and Senior members of
the Team. The outcome of this phase is Software
Requirement Specification.
 Design Phase

• It has two steps:

1. HLD – High Level Design – It gives the architecture of
the software product to be developed and is done by
architects and senior developers.
2. LLD – Low Level Design – It is done by senior
developers. It describes how each and every feature
in the product should work and how every
component should work. Here, only the design will
be there and not the code.
• The outcome from this phase is High Level Document
and Low Level Document which works as an input to
the next phase
 Development Phase

• Developers of all levels (seniors, juniors,

freshers) involved in this phase. This is the
phase where we start building the software
and start writing the code for the product. The
outcome from this phase is Source Code
Document (SCD) and the developed product.
 Testing Phase

• When the software is ready, it is sent to the

testing department where Test team tests it
thoroughly for different defects. They either test
the software manually or using automated testing
tools depends on process defined in STLC
(Software Testing Life Cycle) and ensure that each
and every component of the software works fine.
• Once it is made sure that the software is error-
free, it goes to the next stage, which is
Implementation. The outcome of this phase is the
Quality Product and the Testing Artifacts.
 Deployment & Maintenance Phase
• After successful testing, the product is
delivered/deployed to the customer for their use.
• Deployment is done by the
Deployment/Implementation engineers. Once when
the customers start using the developed system
then the actual problems will come up and needs to
be solved from time to time.
• Fixing the issues found by the customer comes in
the maintenance phase. 100% testing is not possible
– because, the way testers test the product is
different from the way customers use the product.
Maintenance should be done as per SLA (Service
Level Agreement)
 SDLC Models
• There are various software development life cycle models
defined and designed which are followed during the
software development process. These models are also
referred as Software Development Process Models“

• Following are the most important and popular SDLC models

i. Waterfall Model
ii. Iterative Model
iii. Rapid Application Development
iv. Spiral Model
v. Prototyping Model
vi. V-Model
vii. Big Bang Model
Waterfall Model
 ADVANTAGES
DISADVANTAGES
i. Simple to use and understand i. The software is ready only
ii. Management simplicity thanks after the last stage is over
to its rigidity: every phase has ii. High risks and uncertainty
a defined result and process
review iii. Not the best choice for
iii. Development stages go one by complex and object-oriented
one projects
iv. Perfect for the small or mid- iv. Inappropriate for the long-
sized projects where term
requirements are clear and v. The progress of the stage is
not equivocal hard to measure while it is still
v. Easy to determine the key in the development.
points in the development
vi. Integration is done at the very
cycle
end, which does not give the
vi. Easy to classify and prioritize
tasks option of identifying the
problem in advance
 Use cases for the Waterfall SDLC model

• The requirements are precisely documented

• Product definition is stable
• The technologies stack is predefined which
makes it not dynamic
• No ambiguous requirements
• The project is short
 V Model
• It is an extension of the waterfall model.
• Instead of moving down in a linear way, the
process steps are bent upwards after the
implementation and coding phase, to form the
typical V shape.
• The major difference between the V-shaped
model and waterfall model is the early test
planning in the V-shaped model.
• Testing starts in early stages of product
development which avoids downward flow of
defects which in turns reduces lot of rework.
 V Model contd..
• Both teams (test and development) work in
parallel.
• The test team works on various activities like
preparing test strategy, test plan and test
cases/scripts.
• While the development team works on SRS,
Design and Coding.
 V Model contd..
• Once the requirements were received, both the
development and test team start their activities.
• Whilst, developers are working on SRS (System
Requirement Specification).
• Testers work on BRS (Business Requirement
Specification) and prepare ATP(Acceptance Test
Plan) and ATC (Acceptance Test Cases) and so on.
• Testers will be ready with all the required artifacts
(such as Test Plan, Test Cases)  by the time
developers release the finished product. It saves
lots of time.
 STEPS OF V MODEL
1.  Once client sends BRS, both the teams (test and
development) start their activities. The developers
translate the BRS to SRS. The test team involves in
reviewing the BRS to find the missing or wrong
requirements and writes acceptance test plan and
acceptance test cases.
2. In the next stage, the development team sends
the SRS the testing team for review and the
developers start building the HLD (High Level Design
Document) of the product. The test team involves in
reviewing the SRS against the BRS and writes system
test plan and test cases.
 STEPS OF V MODEL
3. In the next stage, the development team starts building the
LLD (Low Level Design) of the product. The test team
involves in reviewing the HLD (High Level Design) and writes
Integration test plan and integration test cases.
4. In the next stage, the development team starts with the
coding of the product. The test team involves in reviewing
the LLD and writes functional test plan and functional test
cases.
5. In the next stage, the development team releases the build
to the test team once the unit testing was done. The test
team carries out functional testing, integration testing,
system testing and acceptance testing on the release build
step by step.
 V MODEL
• The usage
1. Software requirements clearly defined and
known.
2. Software development technologies and tools
are well-known
• Applications
1. Long term projects, complex applications, When
customer is expecting a very high quality product
with in stipulated time frame because every
stage is tested and developers & testers are
working in parallel
 Advantages and Disadvantages

Disadvantages
Advantages
• Simple and easy to use • Very inflexible, like the waterfall
• Each phase has specific model.
deliverables. • Adjusting scope is difficult and
• Higher chance of success over expensive.
the waterfall model due to the • The software is developed during
development of test plans the implementation phase, so no
early on during the life cycle. early prototypes of the software
• Works well for where are produced.
requirements are easily • The model doesn’t provide a
understood. clear path for problems found
• Verification and validation of during testing phases.
the product in the early stages • Costly and required more time,
of product development. in addition to a detailed plan
INCREMENTAL MODEL OR ITERATIVE
ENHANCEMENT MODEL
 Advantages and Disadvantages
Advantages Disadvantages
• Avoids the problems resulting in • Requires planning at the
risk driven approach in the management and technical level
software • Becomes invalid when there is
• Understanding increases through time constraint on the project
successive refinements. schedule or when the users
• Incrementally grows in effective cannot accept the phased
solution after every iteration deliverables.
• Does not involve high complexity
rate
• Early feedback is generated
because implementation occurs
rapidly for a small subset of the
software.
 EVOLUTIONARY MODELS
1. Spiral Model
2. Prototyping model
i. Throwaway/Rapid prototyping
ii. Evolutionary prototyping
iii. Incremental prototyping
iv. Extreme prototyping
 PROTOTYPING MODEL
• Prototypes that evolve into the final system
through an iterative incorporation of user
feedback.
❖The usage
• This process can be used with any software
developing life cycle model. While this shall be
chosen when you are developing a system has
user interactions. So, if the system does not
have user interactions, such as a system does
some calculations shall not have prototypes.
 Advantages and Disadvantages
Advantages Disadvantages
• Reduced time and costs, but • Insufficient analysis. User
this can be a disadvantage if confusion of prototype and
the developer loses time in finished system.
developing the prototypes. • Developer
misunderstanding of user
• Improved and increased
objectives.
user involvement.
• Excessive development time
of the prototype.
• It is costly to implement the
prototypes
 SPIRAL MODEL
• Spiral model works in an iterative nature. It is
a combination of both Prototype development
process and Linear development process
(waterfall model).
• This model place more emphasis on risk
analysis. Mostly this model adopts to the large
and complicated projects where risk is high.
• Every Iteration starts with a planning and ends
with the product evaluation by client.
 SPIRAL MODEL
• Each Phase the Spiral Model undergoes has
the following activities-
1. Planning  – Requirement Gathering, Cost
Estimation, Resource Allocation
2. Risk Analysis – Identify and resolve various
risks, Classify them into different levels, try to
find alternatives and plan ahead
3. Development and Testing– Coding, Internal
Testing and deployment.
4. Evaluation.
 PHASES OF SPIRAL MODEL
1. Phase 1 – Basic Planning or Requirement
Gathering -> analysis risk -> prototype is built ->
customer evaluation.
2. Phase 2 – Prototype refined -> Documentation of
requirements and validate by customers -> final
prototype.
3. Phase 3 – Risk are now known +traditional
approach of development.
• The usage
1. It is used in the large applications and systems
which built-in small phases or segments.
 Advantages and Disadvantages
Advantages Disadvantages
• Estimates (i.e. budget, • High cost and time to reach
schedule, etc.) become the final product.
more realistic as work • Needs special skills to
progressed because evaluate the risks and
important issues are assumptions.
discovered earlier. • Highly customized limiting
• Early involvement of re-usability
developers.
• Manages risks and develops
the system into phases.
 SOFTWARE REQUIREMENTS ANALYSIS,
IDENTIFICATION AND SPECIFICATION

• The requirements analysis and specification phase

starts once the feasibility study phase is complete and
the project is found to be technically sound and
feasible.
• The goal of the requirements analysis and
specification phase is to clearly understand customer
requirements and to systematically organize these
requirements in a specification document.
• This phase consists of the following two activities:
1. Requirements Gathering And Analysis
2. Requirements Specification or documentation.
 Requirements Gathering And Analysis
• The analyst starts requirements gathering and
analysis activity by collecting all information from
the customer which could be used to develop the
requirements of the system.
• He then analyses the collected information to
obtain a clear and thorough understanding of the
product to be developed, with a view to removing
all ambiguities and inconsistencies from the initial
customer perception of the problem.
 Requirements Gathering And Analysis
• After the analyst has understood the exact customer
requirements, he proceeds to identify and resolve the
various requirements problems.
• The most important requirements problems that the
analyst has to identify and eliminate are the problems
of anomalies, inconsistencies, and incompleteness.
• When the analyst detects any inconsistencies, anomalies
or incompleteness in the gathered requirements, he
resolves them by carrying out further discussions with
the endusers and the customers.
 SRS Document
• After the analyst has collected all the
requirements information regarding the software
to be developed, and has removed all the
incompleteness, in consistencies, and anomalies
from the specification, he starts to systematically
organize the requirements in the form of an SRS
document.
• The important parts of SRS document are:
❖ Functional requirements of the system.
❖ Non-functional requirements of the system, and
❖Goals of implementation
 Functional Requirements
• The functional requirements part discusses
the functionalities required from the system.
Here we list all high-level functions {fi} that
the system performs.
• Each high-level function fi, is considered as a
transformation of a set of input data to some
corresponding output data.
• The user can get some meaningful piece of
work done using a high-level function.

INPUT OUTPUT
fi
 IDENTIFY FUNCTIONAL REQUIREMENTS

• The high-level functional requirements often need

to be identified either from an informal problem
description document or from a conceptual
understanding of the problem.
• There can be many types of users of a system and
their requirements from the system may be very
different.
• So, it is often useful to identify the different types
of users who might use the system and then try to
identify the requirements.
 Example
• Consider the case of the library system, where
⮚ F1: Search Book function (fig. 34.2)
⮚ Input: An author’s name
⮚ Output: Details of the author’s books and the location of
these books in the library
 Document Functional Requirements

• For documenting the functional requirements,

we need to specify the set of functionalities
supported by the system.
• A function can be specified by identifying the
state at which the data is to be input to the
system, its input data domain, the output data
domain, and the type of processing to be
carried on the input data to obtain the output
data.
 Example
• Let us first try to document the withdraw-
cash function of an ATM system.
• The withdraw-cash is a high-level
requirement.
• It has several sub-requirements corresponding
to the different user interactions.
• These different interaction sequences capture
the different scenarios.
Example: Withdraw Cash from ATM

• R1: withdraw cash

• Description: The withdraw cash function first
determines the type of account that the user has
and the account number from which the user
wishes to withdraw cash. It checks the balance to
determine whether the requested amount is
available in the account. If enough balance is
available, it outputs the required cash, otherwise
it generates an error message.
Example: Withdraw Cash from ATM
• R1.1: select withdraw amount option
⮚ Input: “withdraw amount” option
⮚ Output: user prompted to enter the account
type
• R1.2: select account type
⮚ Input: user option
⮚ Output: prompt to enter amount
Example: Withdraw Cash from ATM
• R1.3: get required amount
⮚ Input: amount to be withdrawn in integer
values greater than 100 and less than 10,000
in multiples of 100.
⮚ Output: The requested cash and printed
transaction statement.
• Processing: the amount is debited from the
user’s account if sufficient balance is available,
otherwise an error message displayed.
 Non-Functional Requirements

• Non-functional requirements deal with the

characteristics of the system which can not be
expressed as functions - such as the
maintainability of the system, portability of the
system, usability of the system, etc.
• Non-functional requirements may include:
❖Reliability issues
❖ Accuracy of results
❖Human-computer interface issues
❖ Constraints on the system implementation, etc.
 IDENTIFYING NON-FUNCTIONAL
REQUIREMENTS

• Non-functional requirements may include:

1. Reliability issues
2. Performance issues
3. Human - computer interface issues
4. Interface with other external systems
5. Security and maintainability of the system,
etc.
 Goals of Implementation
• The goals of implementation part documents some
general suggestions regarding development.
• These suggestions guide trade-off among design goals.
The goals of implementation section might document
issues such as revisions to the system functionalities
that may be required in the future, new devices to be
supported in the future, reusability issues, etc.
• These are the items which the developers might keep
in their mind during development so that the
developed system may meet some aspects that are
not required immediately.
 Properties of a Good SRS Document

• The important properties of a good SRS

document are the following:
1. Concise
2. Structure
3. Black-box view
4. Conceptual integrity
5. Response to undesired events
6. Verifiable
 Problems without a SRS Document
• The important problems that an organization would face if
it does not develop an SRS document are as follows:

1. Without developing the SRS document, the system would

not be implemented according to customer needs.
2. Software developers would not know whether what they
are developing is what exactly is required by the customer.
3. Without SRS document, it will be very difficult for the
maintenance engineers to understand the functionality of
the system.
4. It will be very difficult for user document writers to write
the users’ manuals properly without understanding the
SRS document.
 Techniques for Representing Complex Logic

• A good SRS document should properly

characterize the conditions under which
different scenarios of interaction occur.
• Sometimes such conditions are complex and
several alternative interaction and processing
sequences may exist.
• There are two main techniques available to
analyze and represent complex processing
logic: decision trees and decision tables.
 Techniques for Representing Complex Logic

• A good SRS document should properly

characterize the conditions under which
different scenarios of interaction occur.
• Sometimes such conditions are complex and
several alternative interaction and processing
sequences may exist.
• There are two main techniques available to
analyze and represent complex processing
logic: decision trees and decision tables.
 Decision Trees

• A decision tree gives a graphic view of the

processing logic involved in decision making
and the corresponding actions taken.
• The edges of a decision tree represent
conditions and the leaf nodes represent the
actions to be performed depending on the
outcome of testing the condition.
 Decision Tables

• A decision table is used to represent the complex

processing logic in a tabular or a matrix form.
• It is useful when variety of action exists and we
need to take a particular action depending upon
the existing condition.
• The upper rows of the table specify the variables
or conditions to be evaluated.
• The lower rows of the table specify the actions to
be taken when the corresponding conditions are
satisfied.
• Every decision table consist of 4 parts :
1. Condition stub
2. Action stub
3. Condition entries
4. Action entries
LMS
 Formal Requirements Specification

• Formal methods which are a broader set of

methods and simply doing the specifications
themselves, specification is part of broader
collection of techniques for formal methods.
• The mathematical basis of a formal method is
provided by the specification language.
Formal Requirements Specification
• The formal method includes three to four steps
typically.
1. Formal specification itself, where the software
requirements are laid out and then specified by
the program or analyst and a formal method
using algebraic steps as we shall see later in this
presentation.
2. Specification analysis and proof, so the
specification can be checked for consistency
which you cannot do in the natural language
kinds of specifications.
Formal Requirements Specification
3. Transformational development, what this really means
in this particular case is that, typically if you take a look
at the software development life cycle process, you go
from requirements to analysis and you go from
requirement analysis to design and each one of these
steps needs to have a certain degree of continuity in
between them. So there is the output of one phase.
• 4. Program verification, refers to checking or testing to
make sure that what we have build indeed conforms to
the specification that was given to us in the first step.
 Merits of Formal Requirements Specification

• Formal methods possess several positive features, some of which

are discussed below.
1. Formal specifications encourage rigour. Often, the very process
of construction of a rigorous specification is more important
than the formal specification itself. The construction of a
rigorous specification clarifies several aspects of system
behaviour that are not obvious in an informal specification.
2. Formal methods usually have a well-founded mathematical
basis. Thus, formal specifications are not only more precise, but
also mathematically sound and can be used to reason about the
properties of a specification and to rigorously prove that an
implementation satisfies its specifications.
3. Formal methods have well-defined semantics. Therefore,
ambiguity in specifications is automatically avoided when one
formally specifies a system.
 Limitations of Formal Requirements Specification

• Formal methods suffer from several shortcomings, some of

which are the following:
1. Formal methods are difficult to learn and use.
2. The basic incompleteness results of first-order logic
suggest that it is impossible to check absolute correctness
of systems using theorem proving techniques.
3. Formal techniques are not able to handle complex
problems. This shortcoming results from the fact that,
even moderately complicated problems blow up the
complexity of formal specification and their analysis. Also,
a large unstructured set of mathematical formulae is
difficult to comprehend.
 Axiomatic Specification

• In axiomatic specification of a system, first-order logic is

used to write the pre and post conditions to specify the
operations of the system in the form of axioms.
• The pre-conditions basically capture the conditions that
must be satisfied before an operation can successfully be
invoked. In essence, the pre-conditions capture the
requirements on the input parameters of a function.
• The post-conditions are the conditions that must be
satisfied when a function completes execution and the
function is considered to have been executed successfully.
• Thus, the post conditions are essentially the constraints on
the results produced for the function execution to be
considered successful.