SOFTWARE ENGINEERING

UNIT 2
 Feasibility study
• The main focus of the feasibility study stage is to determine
whether it would be financially and technically feasible to
develop the software.
– Development of an overall understanding of the problem: It is
necessary to first develop an overall understanding of what the
customer requires to be developed.
– Formulation of the various possible strategies for solving the
problem:
– Evaluation of the different solution strategies: The different
identified solution schemes are analysed to evaluate their benefits
and shortcomings.
• The outcome of the feasibility study phase is that other than
deciding whether to take up a project or not, at this stage very
high-level decisions regarding the solution strategy is defined.
 REQUIREMENTS ANALYSIS AND SPECIFICATION

• The goal of the requirements analysis and specification phase is to

clearly understand the customer requirements and to systematically
organize the requirements into a document called the Software
Requirements Specification (SRS) document.
• The engineers who gather a n d analyze customer requirements and
then write the requirements specification document are known as
system analysts in the software industry
• System analysts collect data pertaining to the product to be developed
and analyze the collected data to conceptualize what exactly needs to
be done.
• After understanding the precise user requirements, the analysts analyze
the requirements to weed out inconsistencies, anomalies and
incompleteness.
• They then proceed to write the software requirements specification
(SRS) document.
 Requirements Analysis and Specification Phase
• Requirements analysis and specification phase
– Requirements gathering and analysis
– Requirements specification
Requirements gathering and analysis
– Requirements gathering
– Requirements analysis
 Requirements Gathering
• Requirements gathering is also popularly
known as requirements elicitation.
• The primary objective of the requirements
gathering task is to collect the requirements
from the stakeholders.
• Availability of a working model is usually of
great help in requirements gathering.
 Requirements Gathering
• Studying existing documentation

• Interview: To systematise this method of requirements gathering, the Delphi

technique can be followed. In this technique, the analyst consolidates the
requirements as understood by him in a document and then circulates it for
the comments of the various categories of users. Based on their feedback,
he refines his document. This procedure is repeated till the different users
agree on the set of requirements

• Task analysis: Task analysis helps the analyst to understand the nitty-gritty of
various user tasks and to represent each task as a hierarchy of subtasks

• Form analysis: During the operation of a manual system, normally several

forms are required to b e filled up by the stakeholders, and in turn they
receive several notifications (usually manually filled forms). In form analysis
the exiting forms and the formats of the notifications produced are analysed
to determine the data input to the system and the data that are output from
the system.
 Requirements Analysis
• The main purpose of the requirements analysis activity
is to analyse the gathered requirements to remove all
ambiguities, incompleteness, and inconsistencies from
the gathered customer requirements and to obtain a
clear understanding of the software to be developed.

• During requirements analysis, the analyst needs to

identify and resolve three main types of problems in the
requirements:
– Anomaly
– Inconsistency
– Incompleteness
 Anomaly
• When a requirement is anomalous, several interpretations of
that requirement are possible. Any anomaly in any of the
requirements can lead to the development of an incorrect
system, since an anomalous requirement can be interpreted
in the several ways during development.

• For example:
suppose one office clerk described the following
requirement: during the final grade computation, if any
student scores a sufficiently low grade in a semester, then his
parents would need to be informed. This is clearly an
ambiguous requirement as it lacks any well defined criterion
as to what can be considered as a “sufficiently low grade”.
 Inconsistency
• Two requirements are said to be inconsistent, if one of the
requirements contradicts the other.
• For example:
suppose one of the clerks gave the following
requirement— a student securing fail grades in three or more
subjects must repeat the courses over an entire semester,
and he cannot credit any other courses while repeating the
courses. Suppose another clerk expressed the following
requirement—there is no provision for any student to repeat
a semester; the student should clear the subject by taking it
as an extra subject in any later semester. There is a clear
inconsistency between the requirements given by the two
stakeholders.
 Incompleteness
• An incomplete set of requirements is one in which some
requirements have been overlooked. The lack of these features
would be felt by the customer much later, possibly while using the
software.
• For Example
Suppose for the case study 4.1, one of the clerks expressed
the following—If a student secures a grade point average (GPA) of
less than 6, then the parents of the student must be intimated
about the regrettable performance through a (postal) letter as well
as through e-mail. However, on an examination of all requirements,
it was found that there is no provision by which either the postal or
e-mail address of the parents of the students can be entered into
the system. The feature that would allow entering the e-mail ids
and postal addresses of the parents of the students was missing,
thereby making the requirements incomplete.
 SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

• After the analyst has gathered all the required information regarding
the software to be developed, and has removed all incompleteness,
inconsistencies, and anomalies from the specification, he starts to
systematically organize the requirements in the form of an SRS
document. The SRS document usually contains all the user
requirements in a structured though an informal form.

• Users of SRS Document

– Users, customers, and marketing personnel
– Software developers
– Test engineers
– User documentation writers
– Project managers
– Maintenance engineers
 SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

• Uses of a well-formulated SRS document

– Forms an agreement between the customers and the
developers
– Reduces future reworks
– Provides a basis for estimating costs and schedules
– Provides a baseline for validation and verification
– Facilitates future extensions
 IEEE Standards for SRS

• As per the IEEE 830 guidelines, the important

categories of user requirements are the following.
• An SRS document should clearly document the
following aspects of a software:
– Functional requirements
– Non-functional requirements
• Design and implementation constraints
• External interfaces required
• Other non-functional requirements
– Goals of implementation.
 Functional requirements
• The functional requirements capture the
functionalities required by the users from the
system
• It is useful to consider a software as offering a
set of functions {fi} to the user.
• These functions can be considered similar to a
mathematical function f : I → O, meaning that
a function transforms an element (ii) in the
input domain (I) to a value (oi) in the output
(O)..
Functional requirements
 Functional requirements
• In order to document the functional requirements of a system, it is necessary to first
learn to identify the high-level functions of the systems by reading the informal
documentation of the gathered requirements.

• The high-level functions would be split into smaller sub-requirements. Each high-level
function is an instance of use of the system (use case) by the user in some way.

• Each high-level requirement typically involves accepting some data from the user
through a user interface, transforming it to the required response, and then
displaying the system response in proper format.

• For example, in a library automation software, a high-level functional requirement

might be search-book. This function involves accepting a book name or a set of key
words from the user, running a matching algorithm on the book list, and finally
outputting the matched books.

• The generated system response can be in several forms, e.g., display on the terminal,
a print out, some data transferred to the other systems, etc.
 Non-functional requirements

• The non-functional requirements are non-

negotiable obligations that must be supported
by the software.
• Non-functional requirements usually address
aspects concerning external interfaces, user
interfaces, maintainability, portability,
usability, maximum number of concurrent
users, timing, and throughput (transactions
per second, etc.)
 Non-functional requirements
• Design and implementation constraints:
– Some of the example constraints can be—corporate or regulatory
policies that needs to be honoured; hardware limitations; interfaces with
other applications; specific technologies, tools, and databases to be
used; specific communications protocols to be used; security
considerations; design conventions or programming standards to be
followed, etc.
• External interfaces required:
– Examples of external interfaces are— hardware, software and
communication interfaces, user interfaces, report formats, etc. To specify
the user interfaces, each interface between the software and the users
must be described.
• Other non-functional requirements:
– This section contains a description of non- functional requirements that
are neither design constraints and nor are external interface
requirements. An important example is a performance requirement such
as the number of transactions completed per unit time.
 Goals of implementation
• The ‘goals of implementation’ part of the SRS
document offers some general suggestions regarding
the software to be developed.
• The goals of implementation section might document
issues such as easier revisions to the system
functionalities that may be required in the future,
easier support for 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.
 How to classify the different types of requirements?

• Non-functional requirements would be tested for

compliance, before the developed product is
accepted by the customer.
• Guideline, on the other hand, are customer request
that are desirable to be done, but would not be
tested during product acceptance.
• Functional requirements form the basis for most
design and test methodologies. Therefore, unless
the functional requirements are properly identified
and documented, the design and testing activities
cannot be carried out satisfactorily.
 How to Identify the 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 first identify the different
types of users who might use the system and then
try to identify the different services expected from
the software by different types of users.
How to Document the Functional Requirements
• Withdraw cash from ATM:
• An initial informal description of a required
functionality is usually given by the customer
as a statement of purpose (SoP).
• An SoP serves as a starting point for the
analyst and he proceeds with the
requirements gathering activity after a basic
understanding of the SoP.
 How to Document the Functional Requirements
• R.1: 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.
• R.1.1: Select withdraw amount option
– Input: “Withdraw amount” option selected
– Output: User prompted to enter the account type
• R.1.2: Select account type
– I n p u t : User selects option from any one of the
followings—savings/checking/deposit.
– Output: Prompt to enter amount
• R.1.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.
 Organization of the SRS Document
• IEEE 830 standard has been intended to serve only as
a guideline for organizing a requirements specification
document into sections and allows the flexibility of
tailoring it, as may be required for specific projects.
• Depending on the type of project being handled,
some sections can be omitted, introduced, or
interchanged as may be considered prudent by the
analyst.
• However, irrespective of the company’s principles and
product type, the three basic issues that any SRS
document should discuss are—functional
requirements, non-functional requirements, and
guidelines for system implementation.
 Organization of the SRS Document
• The introduction section may include the hardware that
the system will run on, the devices that the system will
interact with and the user skill-levels.
• Description of the user skill-level is important, since the
command language design and the presentation styles of
the various documents depend to a large extent on the
types of the users it is targeted for.
• For example, if the skill-levels of the users is “novice”, it
would mean that the user interface has to be very simple
and rugged, whereas if the user-level is “advanced”,
several short cut techniques and advanced features may
be provided in the user interface
 Organization of the SRS Document

• Purpose:
– This section should describe where the software would be
deployed and how the software would be used.
• Project scope:
– This section should briefly describe the overall context within
which the software is being developed. For example, the parts
of a problem that are being automated and the parts that
would need to be automated during future evolution of the
software.
• Environmental characteristics:
– This section should briefly outline the environment (hardware
and other software) with which the software will interact.
 Overall description of organization of SRS document
• Product perspective: This section needs to briefly state as to whether the software
is intended to be a replacement for a certain existing systems, or it is a new
software.
• Product features: This section should summarize the major ways in which the
software would be used.
• User classes: Various user classes that are expected to use this software are
identified and described here.
• Operating environment: This section should discuss in some detail the hardware
platform on which the software would run, the operating system, and other
application software with which the developed software would interact.
• Design and implementation constraints: corporate or regulatory policies;
hardware limitations (timing requirements, memory requirements); interfaces to
other applications; specific technologies, tools, and databases to be used; specific
programming language to be used; specific communication protocols to be used;
security considerations; design conventions or programming standards.
• User documentation: This section should list out the types of user documentation,
such as user manuals, on-line help, and trouble-shooting manuals that will be
delivered to the customer along with the software.
 Functional requirements for organization of SRS document

External interface requirements

• User interfaces: The user interface description may include sample screen
images, any GUI standards or style guides that are to be followed, screen
layout constraints, standard push buttons (e.g., help) that will appear on
every screen, keyboard shortcuts, error message display standards, etc.
• Hardware interfaces: This section may include the description of the
supported device types, the nature of the data and control interactions
between the software and the hardware, and the communication
protocols to be used.
• Software interfaces: This section should describe the connections
between this software and other specific software components, including
databases, operating systems, tools, libraries, and integrated commercial
components, etc.
• Communications interfaces: This section should describe the
requirements associated with any type of communications required by
the software, such as e-mail, web access, network server communications
protocols, etc. This section should define any pertinent message
formatting to be used.
 Non-functional requirements for organization of SRS document

• Performance requirements: Aspects such as

number of transaction to be completed per second
should be specified here.
• Safety requirements: Those requirements that are
concerned with possible loss or damage that could
result from the use of the software are specified
here.
• Security requirements: This section should specify
any requirements regarding security or privacy
requirements on data used or created by the
software. Any user identity authentication
requirements should be described here.
 Personal library software
• 1. Manage books
• 1.1 Register book
– Description: To register a book in the personal library, the details of a book, such as
name, year of publication, date of purchase, price and publisher are entered. This is
stored in the database and a unique serial number is generated.
– Input: Book details
– Output: Unique serial number
• R.1.2: Issue book
– Description: A student can be issued book only if he is registered. The various books
outstanding against him along with the date borrowed are first displayed.
• R.1.2.1: Display outstanding books
– Description: First student’s name and the serial number of the book to be issued are
entered. Then the books outstanding against the student should be displayed.
– Input: student name
– Output: List of outstanding books along with the date on which each was borrowed.
• R.1.2.2: Confirm issue book
– If the owner confirms, then the book should be issued to him and the relevant records
should be updated.
– Input: Owner confirmation for book issue.
– Output: Confirmation of book issue.
 Personal library software
• R.1.3: Query outstanding books
– Description: Details of students who have books outstanding against their name is
displayed.
– Input: User selection
– Output: The display includes the name, address and telephone numbers of each student
against whom books are outstanding along with the titles of the outstanding books and
the date on which those were issued.
• R.1.4: Query book
– Description: Any user should be able to query a particular book from anywhere using a
web browser.
– Input: Name of the book.
– Output: Availability of the book and whether the book is issued out.
• R.1.5: Return book
– Description: Upon return of a book by a student, the date of return is stored and the
book is removed from the borrowing list of the concerned student.
– Input: Name of the book.
– Output: Confirmation message.
 Personal library software

• 2. Manage student details

• R.2.1: Register student
– Description: A student must be registered before he can be issued books. After the registration data is
entered correctly, the data should be stored and a confirmation message should be displayed.
– Input: student details including name of the student, address, and mobile number.
– Output: Confirmation of registration status.
• R.2.2: Update student details
– Description: When a student’s registration information changes, the same must be updated in the
computer.
• R.2.2.1: Display current details
– Input: student name.
– Output: Currently stored details.
• R2.2.2: Update student details
– Input: Changes needed.
– Output: Updated details with confirmation of the changes.
• R.3.3: Delete a student record
– Description: Delete records of inactive members.
– Input: student name.
– Output: Confirmation message.
 Personal library software

• 3. Manage borrowed books

• R.3.1: Register borrowed books
– Description: The books borrowed by the user of the personal library are registered.
– Input: Title of the book and the date borrowed.
– Output: Confirmation of the registration status.
• R.3.2: Deregister borrowed books
– Description: A borrowed book is deregistered when it is returned.
– Input: Book name.
– Output: Confirmation of deregistration.
• R.3.3: Display borrowed books
– Description: The data about the books borrowed by the owner are displayed.
– Input: User selection.
– Output: List of books borrowed from other students.
• 4. Manage statistics
• R.4.1: Display book count
– Description: The total number of books in the personal library should be displayed.
– Input: User selection.
– Output: Count of books.
• R4.2: Display amount invested
– Description: The total amount invested in the personal library is displayed.
– Input: User selection.
– Output: Total amount invested.
• R.4.2: Display number of transactions
– Description: The total numbers of books issued and returned over a specific period by one (or all) student(s) is displayed.
– Input: Start of period and end of period.
– Output: Total number of books issued and total number of books returned.
 Personal library software
• Non-functional requirements
• N.1: Database: A database management system that is available
free of cost in the public domain should be used.
• N.2: Platform: Both Windows and Unix versions of the software
need to be developed.
• N.3: Web-support: It should be possible to invoke the query book
functionality from any place by using a web browser.
• Observation: Since there are many functional requirements, the
requirements have been organised into four sections: Manage own
books, manage students, manage borrowed books, and manage
statistics. Now each section has less than 7 functional requirements.
This would not only enhance the readability of the document, but
would also help in design.
 Techniques for Representing Complex Logic

• a high-level function might involve different steps to be undertaken

as a consequence of some decisions made after each step.
• Sometimes the conditions can be complex and numerous and
several alternative interaction and processing sequences may exist
depending on the outcome of the corresponding condition
checking.
• A simple text description in such cases can be difficult to
comprehend and analyse. In such situations, a decision tree or a
decision table can be used to represent the logic and the
processing involved.
• However, use of decision trees or tables would be superfluous in
cases where the number of alternatives are few, or the decision
logic is straightforward. In such cases, a simple text description
would suffice.
 Techniques for Representing Complex Logic

• There are two main techniques available to

analyze and represent complex processing
logic—
– decision trees and
– decision tables.
• Once the decision making logic is captured in
the form of trees or tables, the test cases to
validate these logic can be automatically
obtained.
 Decision tree

• A decision tree gives a graphic view of the processing

logic involved in decision making and the corresponding
actions taken.
• Decision tables specify which variables are to be tested,
and based on this what actions are to be taken
depending upon the outcome of the decision making
logic, and the order in which decision making is
performed.
• 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 conditions.
 Library membership management software (LMS)

• options—new member, renewal, and cancel membership.

• When the new member option is selected, the software should ask the
member’s name, address, and phone number. If proper information is
entered, the software should create a membership record for the new
member and print a bill for the annual membership charge and the
security deposit payable.
• If the renewal option is chosen, the LMS should ask the member’s name
and his membership number and check whether he is a valid member. If
the member details entered are valid, then the membership expiry date in
the membership record should be updated and the annual membership
charge payable by the member should be printed. If the membership
details entered are invalid, an error message should be displayed.
• If the cancel membership option is selected and the name of a valid
member is entered, then the membership is cancelled, a choke for the
balance amount due to the member is printed and his membership record
is deleted.
Decision tree
 Decision table
• A decision table shows the decision making
logic and the corresponding actions taken in a
tabular or a matrix form.
• The upper rows of the table specify the
variables or conditions to be evaluated and the
lower rows specify the actions to be taken when
an evaluation test is satisfied.
• A column in the table is called a rule. A rule
implies that if a certain condition combination is
true, then the corresponding action is executed.
 Decision table versus decision tree
• Readability:
– Decision trees are easier to read and understand when the number of
conditions are small. On the other hand, a decision table causes the analyst to
look at every possible combination of conditions which he might otherwise
omit.
• Explicit representation of the order of decision making:
– In contrast to the decision trees, the order of decision making is abstracted
out in decision tables. A situation where decision tree is more useful is when
multilevel decision making is required. Decision trees can more intuitively
represent multilevel decision making hierarchically, whereas decision tables
can only represent a single decision to select the appropriate action for
execution.
• Representing complex decision logic:
– Decision trees become very complex to understand when the number of
conditions and actions increase. It may even be to draw the tree on a single
page. When very large number of decisions are involved, the decision table
representation may be preferred.
 Use Case Diagram
• A Use Case Diagram is a vital tool in system design, it provides a
visual representation of how users interact with a system. It serves
as a blueprint for understanding the functional requirements of a
system from a user’s perspective, aiding in the communication
between stakeholders and guiding the development process.

• A Use Case Diagram is a type of Unified Modeling Language (UML)

diagram that represents the interaction between actors (users or
external systems) and a system under consideration to accomplish
specific goals.

• It provides a high-level view of the system’s functionality by

illustrating the various ways users can interact with it.
 Use Case Diagram Notations
Actors
• Actors are external entities that interact with the
system. These can include users, other systems, or
hardware devices
Use Cases
• Use cases are like scenes in the play. They represent
specific things your system can do. In the online
shopping system, examples of use cases could be
“Place Order,” “Track Delivery,” or “Update Product
Information”. Use cases are represented by ovals.
System Boundary
• The system boundary is a visual representation of the
scope or limits of the system you are modeling. It
defines what is inside the system and what is outside.
• Purpose of System Boundary:
– Scope Definition: It clearly outlines the
boundaries of the system, indicating which
components are internal to the system and
which are external actors or entities interacting
with the system.
– Focus on Relevance: the diagram can focus on
illustrating the essential functionalities provided
by the system without unnecessary details
about external entities.
 Types of Association

Association Relationship
• The Association Relationship represents a
communication or interaction between an actor and a
use case. It is depicted by a line connecting the actor
to the use case
 Types of Association
Include Relationship
• The Include Relationship indicates that a use case includes the
functionality of another use case. It is denoted by a dashed arrow
pointing from the including use case to the included use case. This
relationship promotes modular and reusable design.
 Types of Association
Extend Relationship
• The Extend Relationship illustrates that a use case can be extended by another
use case under specific conditions. It is represented by a dashed arrow with
the keyword “extend.” This relationship is useful for handling optional or
exceptional behavior.
 Types of Association

Generalization Relationship
• The Generalization Relationship establishes an “is-a” connection
between two use cases, indicating that one use case is a
specialized version of another. It is represented by an arrow
pointing from the specialized use case to the general use case
 Data Flow Diagrams(CO2)

• Also known as data flow graph or bubble chart.

• It shows the flow of data through a system.
• Used for analyzing existing as well as proposed system
• Focus on movement of data between external entities and
processes, and between processes and data stores.
• It represent a systems in terms of input data to the system, various
processing carried out on those data, and the output data
generated by the system.
• In DFD
– All names should be unique.
– It is not a flow chart. Arrow represent flowing of data without any order.
– Suppress logical decisions.
– Defer error conditions & handling until the end of the analysis.

06/25/2024 MEGHALI DAS Software Engineering ACSE0603 Unit 2 51

 DFD

Source: Entity that supplies data to the system

Sink: Entity that receives data from the system

MEGHALI DAS Software Engineering ACSE0603

06/25/2024 52
Unit 2
 Rules of Data Flow
• Data can flow from
– External entity to process
– Process to external entity
– Process to storage and vice versa
– Process to process
• Data cannot flow from
– External entity to external entity
– External entity to store
– Store to external entity
– Store to store
 Operation in DFD

• Synchronous : if two bubble

are directly connected by a
data flow arrow i.e. they are
operate at the same speed.

• Asynchronous: if two bubble

are connected through a data
store then speed of operation
of the bubble are
independent.

06/25/2024 MEGHALI DAS Software Engineering ACSE0603 Unit 2 54

 Developing DFD model of a system

• Step1: Construction of context diagram. It a top level DFD , usually

called 0 level DFD.(A level 0 DFD is called fundamental system model
or context model represents entire software element as a single
bubble with input and output data indicating by incoming &
outgoing arrows.)
• Step2: Construction of level1 DFD. Expend the process of context
diagram.
• Step3: Construction of lower level DFD. Decompose the process of
level 1 DFD recursively.

06/25/2024 MEGHALI DAS Software E 55

ngineering ACSE0603 U
 A case study of Root Mean Square Calculating System

06/25/2024 MEGHALI DAS Software Engineering ACSE0603 Unit 2 56

 2 and 3 Level DFD

06/25/2024 MEGHALI DAS Software Engineering ACSE0603 Unit 2 57

Context Diagram
Level 1
Level 2 Diagram
 Software Quality Assurance
• Software Quality Assurance (SQA) is simply a way to
assure quality in the software.
• It is the set of activities which ensure processes,
procedures as well as standards are suitable for the
project and implemented correctly.
• Software Quality Assurance is a process which works
parallel to development of software.
• It focuses on improving the process of development of
software so that problems can be prevented before they
become a major issue.
• Software Quality Assurance is a kind of Umbrella activity
that is applied throughout the software process.
 Elements Of Software Quality Assurance
• Standards: The job of SQA is to ensure that standards that have been adopted are followed,
and all work products conform to them.
• Reviews and audits: Technical reviews are a quality control activity performed by software
engineers for software engineers. Their intent is to uncover errors.
• Testing: The job of SQA is to ensure that testing is properly planned and efficiently conducted
for primary goal of software.
• Error/defect collection and analysis: SQA collects and analyzes error and defect data to
better understand how errors are introduced and what software engineering activities are
best suited to eliminating them.
• Change management: SQA ensures that adequate change management practices have been
instituted.
• Education: A key contributor to improvement is education of software engineers, their
managers, and other stakeholders. The SQA organization takes the lead in software process
improvement which is key proponent and sponsor of educational programs.
• Security management: SQA ensures that appropriate process and technology are used to
achieve software security.
• Safety: SQA may be responsible for assessing the impact of software failure and for initiating
those steps required to reduce risk.
• Risk management: The SQA organization ensures that risk management activities are
properly conducted and that risk-related contingency plans have been established.
 SQA Activities
• SQA Management Plan: Make a plan for how you will
carry out the SQA throughout the project.
• Set The Check Points: SQA team should set checkpoints.
Evaluate the performance of the project on the basis of
collected data on different check points.
• Measure Change Impact: The changes for making the
correction of an error sometimes re introduces more
errors keep the measure of impact of change on project.
• Multi testing Strategy.
• Manage Good Relations
• Managing Reports and Records
Statistical Software Quality Assurance
• Information about software defects is
collected and categorized
• Each defect is traced back to its cause
• Using the Pareto principle (80% of the defects
can be traced to 20% of the causes) isolate the
"vital few" defect causes
• Move to correct the problems that caused the
defects
 Statistical Software Quality Assurance
• Causes of errors:
- incomplete or erroneous specification (IES)
- misinterpretation of customer communication (MCC)
- intentional deviation from specification (IDS)
- violation of programming standards (VPS)
- error in data representation (EDR)
- inconsistent module interface (IMI)
- error in design logic (EDL)
- incomplete or erroneous testing (IET)
- inaccurate or incomplete documentation (IID)
- error in programming language translation of design (PLT)
- ambiguous or inconsistent human-computer interface (HCI)
- miscellaneous (MIS)
 Software Reliability
• Software reliability is defined in statistical terms as
the probability of failure-free operation of a computer
program in a specified environment for a specified
time.
MTBF=MTTF+MTTR
MTBF- Mean Time Between Failure
MTTF-Mean Time To Failure
MTTR-Mean Time To Repair
• Availability is the probability that a program is
operating to requirements at a given point in time
Availability=(MTTF/MTBF)X100%
 ISO 9000
• ISO (International Standards Organisation) is a group of
63 countries established to plan and fosters
standardization.
• ISO declared its 9000 series of standards in 1987.
• The ISO 9000 series determines the guidelines for
maintaining a quality system
• The ISO standard mainly addresses operational methods
and organizational methods such as responsibilities,
reporting, etc.
• ISO 9000 defines a set of guidelines for the production
process and is not directly concerned about the product
itself
ISO 9000 series
ISO 9000 series
ISO 9000 series
ISO 9000 series
 CAPABILITY MATURITY MODEL
• CMM is a strategy for improving the software process, to
generate quality software
• The Capability Maturity Model(CMM) is a development model
created after a study of data collected from organizations that
contracted with the U.S. Department of Defence, who funded
research.
• The term “maturity relates to the degree of formality and
optimization of process, from ad hoc practices, to formally
defined steps, to managed result metrics, active optimization of
the processes.
• It is use to judge the maturity of software process an organization
and identify the key practices that are required to increase the
maturity of these process.
• There are 5 levels of CMM
CMM MODEL
 CMMI Model – Maturity Levels
In CMMI with staged representation, there are five maturity levels described as
follows :
• Maturity level 1 : Initial
– processes are poorly managed or controlled.
– unpredictable outcomes of processes involved.
– ad hoc and chaotic approach used.
– No KPAs (Key Process Areas) defined.
– Lowest quality and highest risk.
• Maturity level 2 : Managed
– requirements are managed.
– processes are planned and controlled.
– projects are managed and implemented according to their documented plans.
– This risk involved is lower than Initial level, but still exists.
– Quality is better than Initial level.
• Maturity level 3 : Defined
– processes are well characterized and described using standards, proper procedures, and
methods, tools, etc.
– Medium quality and medium risk involved.
– Focus is process standardization.
 CMMI Model – Maturity Levels
• Maturity level 4 : Quantitatively managed
– quantitative objectives for process performance and quality are set.
– quantitative objectives are based on customer requirements,
organization needs, etc.
– process performance measures are analyzed quantitatively.
– higher quality of processes is achieved.
– lower risk
• Maturity level 5 : Optimizing
– continuous improvement in processes and their performance.
– improvement has to be both incremental and innovative.
– highest quality of processes.
– lowest risk in processes and their performance.
 CMMI Model – Capability Levels
A capability level includes relevant specific and generic practices for a specific process
area that can improve the organization’s processes associated with that process area. For
CMMI models with continuous representation, there are six capability levels as described
below :
• Capability level 0 : Incomplete
– incomplete process – partially or not performed.
– one or more specific goals of process area are not met.
– No generic goals are specified for this level.
– this capability level is same as maturity level 1.
• Capability level 1 : Performed
– process performance may not be stable.
– objectives of quality, cost and schedule may not be met.
– a capability level 1 process is expected to perform all specific and generic practices for this level.
– only a start-step for process improvement.
• Capability level 2 : Managed
– process is planned, monitored and controlled.
– managing the process by ensuring that objectives are achieved.
– objectives are both model and other including cost, quality, schedule.
– actively managing processing with the help of metrics.
 CMMI Model – Capability Levels
• Capability level 3 : Defined
– a defined process is managed and meets the organization’s set of
guidelines and standards.
– focus is process standardization.
• Capability level 4 : Quantitatively Managed
– process is controlled using statistical and quantitative techniques.
– process performance and quality is understood in statistical terms and
metrics.
– quantitative objectives for process quality and performance are
established.
• Capability level 5 : Optimizing
– focuses on continually improving process performance.
– performance is improved in both ways – incremental and innovation.
– emphasizes on studying the performance results across the organization to
ensure that common causes or issues are identified and fixed.