MUTHAYAMMAL COLLEGE OF ARTS AND SCIENCE (AUTONOMOUS)

DEPARTMENT OF COMPUTER APPLICATION

Staff Name:[Link] Class: III BCA C Paper Code: 21M5UCAE01

Paper Name: SOFTWARE ENGINEERING Unit: I

UNIT I
Introduction: The Software Engineering discipline – Program Vs Software products – Why study
Software Engineering – the emergence of software engineering – Notable changes in Software
development practices – Computer System Engineering.
Software Life Cycle Models: Why use a Life Cycle model? – Classical Waterfall Model – Iterative
Waterfall Model – Prototyping model – Evolutionary model – Spiral model – Comparison of
different life cycle models.
I. Introduction
Several fundamental similarities between software engineering and other engineering approaches
such as civil engineering.
These are characterized by the following aspects:
 Heavy use of past experiences. The past experiences are systematically arranged and
theoretical basis for them are also provided wherever possible.
 While designing a system, several conflicting goals might have to be optimized. In such
situations, there may not be any unique solution and thus several alternative solutions
may be proposed.
 A pragmatic approach to cost-effectiveness is adopted and economic concerns are
addressed.
1.1. Software Engineering Discipline – Evolution and Impact
 Evolution of an Art to an Engineering Discipline
 The early programmers used an exploratory programming style.
 In an exploratory programming style, every programmer himself evolves his own software
development techniques solely guided by his intuition, experience, whims, and fancies.
 We can consider the exploratory program development style as an art-since, art is mostly
guided by intuition.
 There are many stories about programmers in the past who were like proficient artists and
could write good programs based on some esoteric knowledge.
 If we analyze the evolution of software development style over the past fifty years.
 Ex: let us consider the evolution of iron-making technology.
 There is no denying the fact that adopting software engineering techniques facilitates
development of high quality software in a cost-effective and efficient manner.

Art Esotric use of past experience

Craft Unorganizd use of past experience

1
 Engineering Systematic use of past experience & formulation of
Scientific basis

1.2. Software Development Projects

 Programs Vs Software Products

Programs Software

Programs are developed by indiviuals Programs have large no. of users and have
for their personal use. good user-interface, proper users manuals &
good documentation support.

Programs are small in size & have Software were large in size & have unlimited
limited functionality functionality

Programs are not properly tested Systematically designed and implemented

For programs little documentation is Software are well documented

expected

Single developer is involved Large developers are involved

Program can be developed according Must be developed using the software

to the programmers engineers

Individual style of development User interface must be carefully designed

Set of instructions Set of programs

1.3. Why study Software Engineering?

The following two skills could be acquired after completing a study of Software engineering:
1. The skill to participate in development of large software products. We can meaningfully
participate in a team effort to develop a large Software product only after learning the
systematic techniques that are being used in the industry.
2. We would learn how to effectively handle complexity in a Software development
problem. In particular, we would learn how to apply the principles of abstraction and
decomposition to handle complexity during software specification, design, construction
and testing.
Besides the above two important skills, we would also be learning the techniques of
software requirements specification user interface development, quality assurance, testing,
project management, maintenance, ec.

1.4. Emergence of Software Engineering

Software engineering techniques have evolved over many years as a result of a series of
innovations and accumulation of program writing experience of writing good quality programs.

2
 a) Early Computer Programming
 Early commercial computers were very slow and too elementary compared to today’s
standards.
 Even simple processing tasks took considerable computation time on those computers.
 Those programs were usually written in assembly languages. Program lengths were typically
limited to about a few hundreds of lines of monolithic assembly code.
 Every programmer developed his own individualistic style of writing programs according to
this intuition and used this style ad hoc while writing different programs.
b) High-Level Language Programming
 Computers became faster with the introduction of the semiconductor technology.
 With the availability of more powerful computers, it became possible to solve larger and
more complex problems.
 High – level languages such as FORTRAN, ALGOL, and COBOL were introduced.
 This considerably reduced the effort required to develop software products and helped
programmers to write larger programs.
c) Control Flow-Based Design
 Programmers found it increasingly difficult not only to write cost-effective and correct
programs, but also to understand and maintain programs written by others.
 To cope up with this problem, experienced programmers advised other programmers to pay
particular attention to the design of the program‘s control flow structure.
 In order to help develop programs having good control flow structures, the flow charting
technique was developed.
 Even today, the flow charting technique is being used to represent and design algorithms.
 2 ways of writing the program code for the same problem.
Fig:1 Unstructured program
1 if(customer_savings_balance > withdrawal_request){
2 100: issue_money=TRUE;
3 GOTO 110; }
4 else if(privileged_customer= =TRUE)
5 GOTO 100;
6 else GOTO120;
7 110: activate_cash_dispenser(withdrawal_request);
8 GOTO 130;
9 120: print(error);
10 130: end-transaction();
Fig:2 Structured program
1 if(privileged_customer||(customer_savings_balance>withdrawal_request)){
2 activate_cash_dispenser(withdrawal_request); }
3
 3 else print(error);
4 end-transaction();
In the example program figure1 we would have to understand the execution paths, and 1-2-3-
7-8-10, 1-4-5-6-9-10 and 1-4-5-2-3-7-8-10. Everyone accepted that it is indeed possible to solve any
programming problem without using GOTO statements and that indiscriminate use of GOTO
statements should be [Link] formed the basis of the structured programming methodology.
A program is call structured when it uses only the sequence, selection and iteration types of
constructs. Structured program avoid unstructured control flows by restricting the use of GOTO
statements.
Example shows the difference b/w structured and unstructured programs
Control Flow diagram
(a) 1 (b)

4
2
1
5
3
3
2
6
7
4
9
8

10

(d) Data Structure-Oriented Design

 As computers become more powerful with the advent of integrated circuits (ICs), they were
used to solve more complex problems.
 Software engineers were now expected to develop larger and more complicated software
products which often required writing in excess of several tens of thousands of ones of
source code.
 More important to pay attention to the design of the important data structures of the
programs than to the design of its control structure.
 Design techniques based on this principle are called data structure-oriented design
techniques.
 Ex: JSP(Jackson’s Structured Programming)
 The JSP methodology provides an interesting technique to derive the program structure from
its data structure representation.
 Several other data structure-based design technique were also developed.
(e) Data Flow-Oriented Design

4
  Computers became still faster and more powerful with the introduction of VLSI Circuits.
 Software engineers looked for more effective techniques for designing software products and
soon data flow-oriented techniques were proposed.
Defn: The function and the data items that are exchanged between the different functions are
represented in a diagram known as a Data Flow Diagram (DFD).
 The program structure is designed from its DFD representation.
 DFD has proven to be generic technique which can be used to model all types of systems,
and not just software systems.
(f) Object-Oriented Design
 Data flow-oriented techniques evolved into Object-Oriented Design (OOD) techniques.
 An object-oriented design technique, objects (such as employees, pay-roll-register, and on)
occurring in a problem are first identified and then the relationships among the objects such
as composition, reference and inheritance are determined.
 Each object essentially acts as a data hiding or data abstraction entity.
 Object-oriented techniques have gained wide acceptance because of their simplicity, code
and design reuse scope they offer, promise of lower development time, lower development
cost, more robust code, and easier maintenance.
(g) Other Developments
 In addition to the advancements made in software design techniques, several other new
concepts and techniques for effective software development have also been introduced.
 These new techniques include life cycle models specification techniques, project
management techniques, testing techniques, debugging techniques, quality assurance
techniques, software measurement techniques, Computer Aided Software Engineering
(CASE) techniques, etc.

Object-Oriented Style

Data Flow-Oriented Style

Data Structure- Oriented Style

Control Flow-Oriented Style

Exploratory Style

1.5. Notable Changes in Software Development Practices:

The following noteworthy difference between these two software development approaches would be
immediately observable

5
  An important difference is that the exploratory software development style is based on error
correction while the software engineering principles are based on error prevention. The
modern practice of software development is to develop the software through several well-
defined stages such as requirements specification design, coding, testing, etc.
 In the exploratory style, coding was considered synonymous with software development.
 It is more cost-effective to prevent errors and in s/w enginering principle emphasize
detection of errors where the error are committed.
 There are several development activities such as design and testing which typically require
much more effort than coding.
 A lot of attention is paid to requirements specification.
 Larger no. of rework is done at a later stage, if the requirement specification is not captured
correctly.
 Rework result in higher cost of development and customer dissatisfaction.
 Periodic reviews are carried out during all stages of the development process.
 The main objectives of carrying out review is phase containment of errors (ie) detect and
correct errors as soon as possible.
 Software testing has become very systematic and standard testing techniques are available.
 There is better visibility of design and code.
 Project planning normally includes preparation of various types of estimates, scheduling, and
development of project tracking plans.
 Several metrics are used to help in software project management and software quality
assurance.
1.6. Computer Systems Engineering
 In a mobile communication system, there is a special processor and it can run only the
programs written specifically for it.
 Development of such systems entails development of both software and specific hardware
that would run the software.
 Computer systems engineering addresses development of such systems that require
development of both software and specific hardware that run the software.
 One of the important stages in systems engineering is the stage in which decision is made
regarding the parts of the problems that are to be implemented in hardware and the ones that
would be implemented in software.
 In systems engineering, testing the software during development becomes a tricky issue, as
the hardware on which the software would run and tested would normally be still under
development – remember that the hardware and the software are being developed at the same
time.
 To test the software during development, it therefore usually becomes necessary to develop
simulators that mimic the features of the hardware being developed.
 The project management activity is required throughout the duration of system development
as shown in the fig.

6
 Feasibility Study

Requirements
analysis and Hardware
specifications Developme
nt Integration Maintenanc
Hardware and testing e
Software
partitioning
Software
developme
nt
Project Management

II. Software Life Cycle Models

 A software life cycle is the series of identifiable stages that a software product undergoes
during its lifetime.
 The subsequent stages are: requirements analysis and specification, design , coding, testing
and maintenance. Each of these stages is called a life cycle phase.
 A software life cycle model is a descriptive and diagrammatic representation of the
software life cycle.
 A life cycle model represents all the activities required to make a software product transit
through its life cycle phases.
 Most business organizations carry out their business through some sequence of well-defined
steps (called business process). Similarly, manufacturing industries follow certain steps to
develop their product (called manufacturing process).
 A process covers all the activities beginning from product inception through delivery and
retirement.
Why Use a Life Cycle Model?
 The primary advantage of adhering to a life cycle model is that it encourages development of
software in a systematic and disciplined manner.
 When a program is developed by a single programmer, he has the freedom to decide the
exact steps through which he will develop the program.
 Suppose the team members are allowed the freedom to develop the parts assigned to them in
whatever way they like.
 It is possible that one member might start writing the code for his part, another might decide
to prepare the test assigned to prepare the test document first, and some other engineer might
begin with the design phase of the parts assigned him. This would be one of the perfect
recipes for project failure.
Why Document a Life Cycle Model?
 A documented life cycle model, besides preventing the misinterpretations that occur when
the life cycle model is not adequately documented, also helps in identifying inconsistencies,
redundancies, and omissions in the development process.
7
  Advantage: that it enhances the understanding of the process among the developers and
mandates the software development organization to accurately define every activity in the
life cycle.
 A documented life cycle model is also a mandatory requirement of the modern quality
assurance techniques.
Phase Entry and Exit Criteria
 A phase can begin only when the corresponding phase-entry criteria are satisfied.
 A phase can be considered to be complete only when the corresponding exit criteria are
satisfied.
 The phase-exit criteria for the software requirements specification phase
 Ex: can be that the Software Requirements Specification (SRS) document has been
developed, internally reviewed and approved by the customer.
 If there is no clear specification of the entry and exit criteria for every phase, and if no life
cycle model is followed, it becomes very difficult to chart the progress of the project.
 Several life cycle models have been developed.
2.1. Classical Waterfall Model
 The classical waterfall model is intuitively the most obvious way to develop software.
 We can consider this model to be a theoretical way of developing software.
 The classical waterfall model divides the life cycle into the phases shown in the fig.
 The name of this model is justified by its diagrammatic representation which resembles a
cascade of waterfalls.
 This model breaks down the life cycle into an intuitive set of phases.
 The different phases of this model are: feasibility study, requirements analysis and
maintenance.
 The different phases starting from the feasibility study to the integration and system testing
phase are known as the development phases.
 The part of the life cycle model between the feasibility study and product testing and
delivery is known as the development part.
 At the end of the development part of the life cycle, the product becomes ready to be
delivered to the customer.
 The maintenance phase commences after completion of the development phase.
Feasibility Study
Requirements analysis and
Specification
Design
Coding and Unit Testing
Integration and system testing
Maintenance

8
  Observe that among all the life cycle phases, the maintenance phase normally requires the
maximum effort.
 Each phase of the life cycle has well-defined starting and ending criteria which typically
need to be documented in the form of text description.
Feasibility Study
 Aim: To determine whether it would be financially and technically feasible to develop the
product.
 The feasibility study activity involves the analysis of the problem and collection of all
relevant information relating to the product such as the different data items which would be
input to the system, the processing. required to be carried out on these data, the output data
required to be produced by the system, as well as various constraints of the system.
o An abstract problem definition. An abstract problem definition is a rough description
of the problem which considers only the important requirements and ignores the rest.
o Formulation of the different solution strategies.
o Analysis of alternative solution strategies to compare their benefits and shortcomings.
This analysis usually requires making approximate estimates of the resources
required, cost of development time for each of the options. T
o These estimates are used as the basis for comparing the different solutions. Once the
best solution is identified, all later phases of development are carried out as per this
solution.
Requirements Analysis and Specification
 Aim: To understand the exact requirements of the customer and to document them properly.
 This phase consists of two distinct activities:
 Requirement Gathering
 Requirement Specification
Requirements Gathering and Analysis
 Goal: To collect all relevant information from the customer regarding the product to be
developed with a clear view.
 The requirements analysis activity is begun by collecting all relevant data regarding the
product to be developed from the users of the product and from the customer through
interviews and discussions.
 Example: to perform the requirements analysis of a business accounting software required by
an organization, the analyst might interview all the accountants of the organization to
ascertain their requirements.
Requirements Specification
 The customer requirements identified during the requirements gathering and analysis activity
are organized into a SRS document.
 The important components of this document are the functional requirements, the
nonfunctional requirements, and the goals of implementation.
 Each function can be characterized by the input data, the processing required on the input
data, and the output data to be produced.
9
  The nonfunctional requirements identify the performance requirements, the required
standards to be followed, etc.
 The SRS document is written using the end-user terminology,
 The SRS document serves as a contract between the development team and the customer.
 The SRS document provides the basis for carrying out all the development activities.
 The SRS document produced at the end of this phase is also called the black-box
specification of the problem – external behavior is only specified.

Input Output
Design
System
 Goal: To transform the requirements specified in the SRS document into a structure that is
suitable for implementation in some programming language.
 During the design phase the software architecture is derived from the SRS document.
Two Approaches:
- Traditional Design Approach
- Object-Oriented Design Approach
Traditional Design Approach
 It is currently being used by many software development houses.
 It consists of two different activities:
o Structured Analysis of the requirements specification is carried out where the
detailed structure of the problem examined. This is followed by a structured
design activity.
 Data Flow Diagrams (DFDs) – perform structured analysis and to document the
results.
 Structured design consists of two main activities: architectural design & detailed
design.
Object-Oriented Design Approach
 Object-Oriented Design (OOD) is a relatively new technique.
 Various objects that occur in the problem domain and the solution domain are first identified
and the different relationships that exist among these objects are identified.
 Benefits: lower development time and effort, better maintainability of the product.
Coding and Unit Testing
 Purpose: 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.
 A coding standard addresses issues such as the standard ways of laying out the program
codes, the template for laying out the function and module headers, commenting guidelines,

10
 variable and function naming conventions, the maximum number of source lines permitted in
each module.
 Each module is unit tested to determine the correct working of all the individual modules.
 It involves testing each module in isolation from other modules, then debugging and
documenting it.
Integration and System Testing
 Integration of different modules in a planned manner.
 Goal of System Testing: to ensure that the developed system conforms to its requirements
laid out in the SRS document.
 After all modules have been successfully integrated & tested, system testing is carried out.
 Three kinds of Testing Activities are
 α-testing: It is the system performed by the development team.
 β-testing: It is the system performed by a friendly set of customers.
 Acceptance testing: It is the system performed by the customer himself after the
product delivery to determine whether to accept or reject the delivered product.
 System testing is normally carried out in a planned manner according to the System test
Plan.
 The results of integration and system testing are documented in the form of a test report.
Maintenance
 Maintenance of a typical software product requires which much more effort than the effort
necessary to develop the product itself.
 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. This is called adaptive
maintenance.

2.2. Iterative Waterfall Model

 The classical waterfall model is an idealistic one since it assumes that no development error
is ever committed by the engineers during any of the life cycle phases.
 The source of the defects can be many: oversight, wrong assumptions, use of inappropriate
technology, communication gap among the project engineers, etc.
 These defects usually get detected much later in the life cycle.
 Fig: to allow for the correction of the errors committed during a phase that are detected in
later phases.

11
Feasibility Study
Requirements analysis and Specification

Design
Coding and Unit Testing

Integration and system testing

Maintenance

 However, it may not always be possible to detect all the errors in the same phase in which
they occur.
 Nevertheless, the errors should be detected as early as possible.
 An important technique used is to conduct reviews after every milestone.
 In spite of the best effort put into detect errors in the same phase in which they were
committed, some errors do escape detection and may get noticed only in the later phases.
Shortcomings of the waterfall model are the following:
 The waterfall model cannot satisfactorily handle the different types of risks that a real-life
software project is subjected to.
 To achieve better efficiency and higher productivity, most real-life projects cannot follow the
rigid phase sequence imposed by the waterfall model. A rigid adherence to the waterfall
model creates “blocking states” in the system.
2.3. Prototyping Model
 The prototyping model suggests that before carrying out the development of the actual
software, a working prototype of the system should be built. A prototype is a toy
implementation of the system.
 The prototype is built using several shortcuts involving inaccurate or dummy functions.
 The first phase is prototype development to control various risks.
 Next phase is followed by an iterative development cycle.
 Protyping starts with an initial requirements gathering phase.
 Quick design is carried out and a prototype is built.
 The developed prototype is submitted to the customer for his evaluation.
 This cycle of obtaining customer feedback and modifying the prototype continues till the
customer approves the prototype.
 Once the customer approves, the actual system is developed using iterative development
phase.

12
  By constructing the prototype and submitting it for user evaluation, many customer
requirements get properly defined and technical issues get resolved by experimentally
with the prototype.
 This minimizes the change requests from the customer and the associated redesign cost.

Requirements gathering

Quick Design

Refine requirements
incorporating customer Build Prototype
suggestions

Customer evaluation
of prototype

Acceptance
by customer Design

Implement

Test
Maintain

2.4. Evolutionary Model

 This life cycle model is referred to as the Successive Versions model and sometimes as the
incremental model.
 In this model, the software is first broken down into several modules which can be
incrementally constructed and delivered.

A
BB A
A B A
A

 B
The development team first develops the core modules of the system.
 This initial product skeleton is refined into increasing levels of capability by adding new
functionalities in successive versions. C
 The core modules are those that do not need services from other modules.
 Non-core modules need services from the core modules.
 Collect the customer feedback and modify the requirements.

13
  The development team develops the next modules and the same iterative process is
continued till all the modules get completed.
 Finally, the developed feature pass on to the maintenance phase.
 The evolutionary model is shown in Fig.

Rough requirements Specification

Identify the core and other parts to be developed incrementally

Develop the core part using an iterative waterfall model

Collect customer feedback and modify requirements

Develop the next identified features using an iterative waterfall

Maintenance

Advantages
 The user gets a chance to experiment with a partially developed software much before the
complete version of the system is released.
 It helps to accurately elicit user requirements during the delivery of the different versions of
the software, and the change requests therefore after delivery of the complete software are
minimized.
 Also, the core modules get tested thoroughly, thereby reducing chances of errors in the core
modules of the final model.
Disadvantages
 The successive versions model is that for most practical problems it is difficult to divide the
problem into several functional units which can be incrementally implemented and
delivered.

[Link] Model
 The spiral model of software development is shown.
 The diagrammatic representation of this model appears like a spiral with many loops.
 The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a
phase of the software process.

14
  1st quadrant identifies the objectives of the phase and the alternative solutions possible for
the phase under consideration.
 During the 2nd quadrant, the alternative solutions are evaluated to select the best solution
possible.
 For the chosen solution, the potential risks are identified and dealt with by developing an
appropriate prototype.
 A risk is essentially any adverse circumstance that might hamper the successful completion
of a software project.
 During the 3rd quadrant consist of developing and verifying the next level of the product.
 4th concern reviewing the results of the stages traversed so far with the customer and
planning the next iteration around the spiral.
 In this model of development, the project team must decide how exactly to structure the
project into phases.
 The spiral model can be viewed as a meta model, since it subsumes all the above discussed
models.
[Link] of different Life Cycle Models
 The classical waterfall model can be considered as the basic model and all other life
cycle models embellishments of his model. However, the classical waterfall model
cannot be used in practical development projects, since this model supports no
mechanism to correct the errors that are committed during any of the phases but detected
at a later phase.
 The above problem is overcome by the iterative waterfall model through the
provision of feedback paths.

15
 The iterative waterfall model is probably the most widely used software development
model so far. His model is simple to understand and use. However, this model is suitable
for well – understood problems, and is not suitable for very large projects and for
projects that suffer from many types of risks.
 The prototyping model is suitable for projects for which either the user requirements or
the underlying technical aspects are not well understood, however all the risks can be
identified before the project starts. This model is especially popular for development of
the user interface part of the projects.
 The evolutionary approach is suitable for large problems which can be decomposed into
a set of modules for incremental development and delivery. This model is also used
widely for object – oriented development projects. Of course, this model can also be used
if incremental delivery of the system is acceptable to the customer.
 The Spiral model is considered a meta model and encompasses all other life cycle models.
Flexibility and Risk handling are inherently built into this model. This spiral model is
suitable for development of technologically challenging and large software products that
are prone to several kinds of risks that are difficult to anticipate at the start of the project.
However, this model is much more complex that the other models – this is probably a
factor determining its use in ordinary projecs.

16
 MUTHAYAMMAL COLLEGE OF ARTS AND SCIENCE (AUTONOMOUS)
DEPARTMENT OF COMPUTER APPLICATION

Staff Name:[Link] Class: III BCA C Paper Code: 21M5UCAE01

Paper Name: SOFTWARE ENGINEERING Unit: II

Unit – II
Requirements Analysis and Specification: Requirements Gathering and Analysis –
Software Requirements Specification (SRS) – Formal System Development Techniques.
Software Design: Characteristics of a Good Software Design – Cohesion and Coupling
– Neat Arrangement – Software Design Approaches – Object-Oriented Vs Function –
Oriented Design.

[Link] Analysis and Specification

- The requirements analysis and specification phase starts once the feasibility study phase is
complete and the project is found to be financially sound and technically feasible.
- The goal of the requirements analysis and specification phase is to clearly understand the
customer requirements and to systematically organize these requirements in a specification
document.
- Two activities:
o Requirements gathering and analysis
o Requirements specification
- The engineers who gather and analyze customer requirements and write the requirements
specification document are known as system analysts in the software industry parlance.
- System analysts collect data pertaining to system analysts in the software industry these data
to conceptualize what exactly needs to be done.
- Once the system analyst understands the precise user requirements.
- The SRS document is the final output of the requirements analysis and specification phase.

2.1.1. Requirement Gathering and Analysis

- The analyst starts the requirements gathering and analysis activity by collecting all
information from the customer which could be used to develop the requirements of the
system.
- It is very difficult to gather the necessary information and to form an unambiguous
understanding of a problem.
- This is especially so if there are no working models of the problem.
- If the product involves developing something new for which no working model exists, then
the requirements gathering and analysis activities become all the more difficult.
Requirements Gathering
 This activity typically involves interviewing the end-users and customers and
studying the existing documents to collect all possible information regarding the
system.
Analysis of gathered Requirements
1
  The main purpose of this activity is to clearly understand the exact requirements of
the customer.
The following basic questions pertaining to the project should be clearly understood by
the analyst in order to obtain a good grasp of the problem:
 What is the problem?
 Why is it important to solve the problem?
 What are the possible solutions to the problem?
 What are the likely complexities that might arise while solving the problem?
 Anomaly: An anomaly is an ambiguity in the requirement. When a requirement is
anomalous, several interpretations of the requirement are possible.
 Inconsistency: The requirements become inconsistent, if any one of the requirements
contradicts another.
 Incompleteness: An incomplete requirement is one where some of the requirements have
been overlooked. Often, incompleteness is caused by the inability of the customer to
visualize and anticipate all the features that would be required in a system to be
developed.
 If the requirements are specified and studied using a formal method, then many of these
subtle anomalies and inconsistencies can get detected. Once a system has been formally
specified, it can be systematically analyzed to remove all problems from the
specification.

2.1.2. Software Requirements Specification (SRS)

The SRS document usually contains all the user requirements in the informal form.
Different people need the SRS document for very different purposes. Some of the important
categories of users of the SRS document and their needs are as follows:
 Users, customers, and marketing personnel: The goal of this set of audience is to ensure
that the system as described in the SRS document will meet their needs.
 Software Developers: The software developers refer to the SRS document to make sure that
they develop exactly what is required by the customer.
 Test Engineers: Their goal is to ensure that the requirements are understandable from a
functionality point of view, so that they can test the software and validate its working.
 User Documentation Writers: Their goal in reading the SRS document is to ensure that
they understand the document well enough to be able to write the users manuals.
 Project Managers: They want to ensure that they can estimate the cost easily by referring
to the SRS document and that it contains all the information required to plan the project well.
 Maintenance Engineers: the SRS document helps the maintenance engineers to understand
the functionality of the system. A clear knowledge of the functionality can help them to
understand the design and code.
- Many software engineers in a project consider the SRS document as a reference document.
- The SRS document can even be used as a legal document to settle disputes between the
customers and the developers.
- Once the customer agrees to the SRS documents, the development team proceeds.

2
CHARACTERISTICS OF A GOOD SRS

1. Correctness: User review is used to ensure the correctness of requirements stated in the SRS.
SRS is said to be correct if it covers all the requirements that are actually expected from the
system.
2. Completeness: Completeness of SRS indicates every sense of completion including the
numbering of all the pages, resolving the to be determined parts to as much extent as possible as
well as covering all the functional and non-functional requirements properly.
3. Consistency: Requirements in SRS are said to be consistent if there are no conflicts between
any set of requirements. Examples of conflict include differences in terminologies used at
separate places, logical conflicts like time period of report generation, etc.
4. Unambiguousness: A SRS is said to be unambiguous if all the requirements stated have only 1
interpretation. Some of the ways to prevent unambiguousness include the use of modeling
techniques like ER diagrams, proper reviews and buddy checks, etc.
5. Ranking for importance and stability: There should a criterion to classify the requirements as
less or more important or more specifically as desirable or essential. An identifier mark can be
used with every requirement to indicate its rank or stability.
6. Modifiability: SRS should be made as modifiable as possible and should be capable of easily
accepting changes to the system to some extent. Modifications should be properly indexed and
cross-referenced.
7. Verifiability: A SRS is verifiable if there exists a specific technique to quantifiably measure the
extent to which every requirement is met by the system. For example, a requirement starting that
the system must be user-friendly is not verifiable and listing such requirements should be
avoided.
8. Traceability: One should be able to trace a requirement to design component and then to code
segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.
9. Design Independence: There should be an option to choose from multiple design alternatives
for the final system. More specifically, the SRS should not include any implementation details.
10. Testability: A SRS should be written in such a way that it is easy to generate test cases and test
plans from the document.
11. Understandable by the customer: An end user maybe an expert in his/her specific domain but
might not be an expert in computer science. Hence, the use of formal notations and symbols
should be avoided to as much extent as possible. The language should be kept easy and clear.
12. Right level of abstraction: If the SRS is written for the requirements phase, the details should
be explained explicitly. Whereas, for a feasibility study, fewer details can be used. Hence, the
level of abstraction varies according to the purpose of the SRS.

CHARACTERISTICS OF BAD SRS

Some of the important categories of problems that many SRS documents suffer from are as
follows:
 Over-specification: It occurs when the analyst tries to address the “how to” aspects in the
SRS document. For example, in the library automation problem, one should not specify
whether the library membership records need to be stored indexed on the member’s
first name or on the library member’s identification (ID) number. Over-specification
restricts the freedom of the designers in arriving at a good design solution.
 Forward references: One should not refer to aspects that are discussed much later in the
SRS document. Forward referencing seriously reduces readability of the specification.

3
  Wishful thinking: This type of problems concern description of aspects which would be
difficult to implement.
 Noise: The term noise refers to presence of material not directly relevant to the software
development process. For example, in t h e register customer function, suppose the
analyst writes that customer registration department is manned by clerks who report for
work between 8am and 5pm, 7 days a week. This information can be called noise as it
would hardly be of any use to the software developers and would unnecessarily clutter
the SRS document.

2.1.3. 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 sequence may exit
- A simple text description, in cases where complex conditions would have to be checked and
large number of alternatives might exist, would be difficult to comprehend and analyze.
- 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 the logic can be automatically obtained.
Decision tree
- A decision tree gives a graphical 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.

Example - A library membership management software (LMS) should support the following
three 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. The decision
tree representation for this problem is shown.

4
In the decision tree of Figure above, first the user selection is checked. Based on whether the
selection is valid, either further condition checking is undertaken or an error message is displayed.
Observe that the order of condition is explicitly represented.
Decision table
- Decision tables specify which variables are to be tested, and based on this what actions need
to be taken depending upon the outcome of the decision making logic, and the order in which
decision making is performed.
- 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.
- Table 4.1: Decision Table for the LMS Problem

Conditions
Valid selection NO YES YES YES
New member - YES NO NO
Renewal - NO YES NO
Cancellation - NO NO YES
Actions
Display error message ×
Ask member’s name, etc. ×
Build customer record ×
Generate bill × ×
Ask membership details × ×
Update expiry date ×
Print cheque ×
Delete record ×

5
2.2. SOFTWARE DESIGN
- Software design deals with transforming the customer requirements, as described in the SRS
document, into a form that is implementable using a programming language.
- The objectives of the design phase are to take the SRS document as the input and produce
the above mentioned documents before completion of the design phase.
- Definition: The activities carried out during the design phase (called as design process )
transform the SRS document into the design document.

 Design Process
SRS Document Design Document

OUTCOME OF A DESIGN PROCESS

 Different modules required: The different modules in the solution should be clearly
identified. Each module is a collection of functions and the data shared by the functions
which accomplish a well-defined task.
 Control relationships among modules: Defines function calls between the two modules.
 Interfaces among different modules: Defines exact data items to be exchanged when 2
modules are invoked each other.
 Data structure of the individual modules: Suitable data structures to be properly designed
and documented.
 Algorithm Requirement: Defines the suitable algorithm to accomplish module processing
activities.

1. Classification of Design Activities

- The design activities divided into two important parts
o Preliminary design (outcome : Program structure)
 A problem is decomposed into a set of modules, the control relationship and
the interfaces among various modules are identified.
o Detailed design (outcome : module specification)
 During detailed design, each module is examined carefully to design itys data
structure and the algorithms.
- The meaning and scope of these two activities tend to vary considerably from one
methodology to another.
- The outcome of high level design is called the program structure or software
architecture.
- A large number of software design techniques are available.

2. Classification of Design Methodologies

- The design activities vary considerably based on the specific design methodology being
used. A large number of software design methodologies are available.
- We can roughly classify these methodologies into procedural and object-oriented
approaches.
- These two approaches are two fundamentally different design paradigms.

3. Analysis Vs design activities (differ in goal and scope)

- The goal of any analysis technique is to elaborate the customer requirements through
6
 careful thinking and at the same time consciously avoiding making any decisions
regarding the exact way the system is to be implemented.

2.2.1. CHARACTERISTICS OF A GOOD SOFTWARE DESIGN

- A definition of a good software design can vary depending on the application for which it is
being designed.
- For example, the memory size used up by a program may be important issues to characterize
a good solution for embedded software development since embedded applications are often
required to be implemented using memory of limited size due to cost, space or power
consumption constraints.
- Most researchers and software engineers agree on a few desirable characteristics that every
good software design for general applications must process.
- The characteristics are listed below
 Correctness: A good design should first of all be correct. That is, it should correctly
implement all the functionalities of the system.
 Understandability: A good design should be easily understandable. Unless a design
solution is easily understandable, it would be difficult to implement and maintain it.
 Efficiency: A good design solution should adequately address resource, time, and cost
optimization issues.
 Maintainability: A good design should be easy to change. This is an important
requirement, since change requests usually keep coming from the customer even after
product release.
- In order to facilitate understandability of a design, the design should have the following
features
- It should assign consistent and meaningful names to various design components.
- It should make use of the principles of decomposition and abstraction in good
measures to simplify the design.
- It should neatly arrange the modules in a hierarchy. Ex. Tree like diagram
- A design solution should be modular and layered to be understandable.
- We now elaborate the concepts of modularity, clean decomposition, and neat arrangement of
modules.
 Modularity
- A design solution is said to be highly modular, if the different modules in the
solution have high cohesion and their inter-module couplings are low.
- The problem has been decomposed into a set of modules.
- divide and conquer principle.
- If different modules are independent of each other, then each module can be
understood separately.
 Layered
- It is used to define a large collection of different modules in a tree- like diagram
with clear layering.
 Clean decomposition
- It means that the modules in a software design should display high cohesion and low
coupling.
 Neat Arrangement
- This aspect is essentially characterized by the following
7
 o Layered solution
o Low fan out
o Abstraction
2.2.2. COHESION AND COUPLING
Cohesion is a measure of the functional strength of a module whereas the coupling between two
modules is a measure of the degree of interdependence or interaction between the two modules.
- A module having high cohesion and low coupling is said to be functionality independent of
other modules.
- By the term functional independence, we mean that at cohesive module performs a single
task or function
- A functionality independent module has minimal interaction with other modules.
- Functional independence is a key to any good design primarily due to the following reason
Error isolation
- Functional independence reduces error propagation. The reason behind this is that if a
module is functionally independent.
- Its degree of interaction with other modules is less.
- Therefore, any error existing in a module would not directly affect the other modules
Scope for reuse
- Reuse of a module becomes possible, because each module does some well defined and
precise functions, and the interface of the module with other modules is simple and minimal.
- Therefore, a cohesive module can be easily taken out and be reused in a different program
Understandability
- Complexity of the design is reduces, because different modules are more or less independent
of each other can be understood in isolation.

Classification of Cohesiveness
Coincidental cohesion - A module is said to have coincidental cohesion, if it performance a set of
tasks that relate to each other very loosely. The module contains a random collection of functions. It

8
is likely that the functions have been put in the module out of pure coincidence without any though
or design.
Logical cohesion - A module is said to be logically cohesive, if all elements of the module perform
similar operations.
Temporal cohesion - When a module contains functions that are related by the fact that all the
functions must be executed in the same time span, the module is said to exhibit temporal cohesions.
The set of functions responsible for initialization, start up shut down of some process etc. exhibit
temporal cohesion
Procedural cohesion - A module is said to posses procedural cohesion, if the set of functions of the
module are all part of procedure in which certain sequence of steps has to be carried out for
achieving an objective
Communicational cohesion - A module is said to have communicational cohesion, if all the
functions of the module refer to or update the same data structure
Sequential cohesion - A module is said to process sequential cohesion, it the elements of module
form the parts of sequence, where the output from one element of the sequence is input to the next.
Functional cohesion - Functional cohesion is said to exit, if the different elements of a module
cooperate to achieve a single function.
Classification of coupling
- The coupling between two modules indicates the degree of interdependence between them.
- Intuitively, if two modules interchange large amounts of data, then they are highly
interdependent.
- The degree of coupling between two modules depends on their interface complexity
- Five type of couplings can occur between any two modules
Data coupling - Two modules are data couples, if they communicate using and elementary
data item that is passed as a parameter between the two.
Stamp coupling - Two modules are stamp coupled, if they communicate using a composite
data item such as a record in PASCAL or a structure in C.
Control coupling - Control coupling exits between two modules, if data from one module is
used to direct the order of instruction execution in another. An example of control coupling
is a flag set in one module and tested in another module.
Common coupling - Two modules are common coupled, if they share some global data
items.
Content coupling - Content coupling exists between two modules, if their code is shared
ex. A branch from one module into another module

9
2.2.3. NEAT ARRANGEMENT
- The control hierarchy represents the organization of the program components.
- The control hierarchy is also called program structure.
- Many different types of notations have been used to represent the control hierarchy.
Layering
- In a layered design solution, the modules are arranged in layers.
- The control relationship among modules in a layer is expressed in the following way.
- A module that controls another module is said to be super ordinate.
- A module controlled by other module is subordinate to it.
- Conversely, module hierarchies also represent a subtle characteristic of software
architecture.
Control abstraction
- A module should invoke the functions of the modules in the layer immediately below it.
- A module at a lower layer, should not invoke the service of the module.
Depth and Width
- These provide an indication of the number of levels of controls and the overall span of
control respectively
Fan out
- It is a measure of the number of modules that are directly controlled by a given module
- A design having modules with high fan out numbers is not a good design as such module
would lack cohesion
Fan in
- It indicated the number of modules directly invoking a given module. High fan is
representing code reuse and is, in general encouraged.
2.2.4. SOFTWARE DESING APPROACHES
There are fundamentally two different approaches to software design – function oriented design, and
object oriented design.
- However, these two design approaches are radically different.
Function oriented design
10
 1. A system is viewed as something that performs a set of functions. Starting at this high level
view of the system, each function is successively refined into more detailed functions. For
example consider a function create new library member which essentially creates the
recorded for a new member, assigns a unique membership number to the new member, and
prints a bill towards the membership charge. This function may consist of the following sub
functions.
 Assign membership number
 Create member record
 Print bill
2. The system state is centralized and shared among different functions.
 Create new member
 Delete member
 Update member record
Object oriented design
- In the object oriented design approach, the system is viewed as a collection of objects.
- The system state is decentralized among the objects and each object to manage its own state
information.
- Objects have their own internal data which define their state.
- Similar objects constitute a class.
- In other words, each object is a member of some class
- Classes may inherit feature from a super class.

[Link] ORIENTED VS FUNCTION ORIENTED DESIGN

- Unlike function oriented design methods, in ODD the basic abstractions are not real world
functions such as sort, display track etc.,
- But real world entities such as employee, picture, machine radar system etc
- In ODD, state information is not represented in a centralized shard memory but is distributed
among the objects of the system.
- Function oriented techniques, such as SA/SD group the functions together if as a group they
constitute a higher level function
Fire alarm system
- The fire alarm system would monitor the status of these smoke detectors.
- Whenever a fire condition is reported by any of the smoke detectors, the fire alarm system
should determine the location at which the fire condition has occurred and then sound the
sirens only in the neighboring locations
- The fire alarm system should also flash and alarm message on the computer console.
Function oriented approach
The functions which operate on the system state are
interrogate_detectors ();
get_detector_location ();
determine_neighbour ();
ring_alarm ();
reset_alarm ();

11
 report_fire_location ();
Object oriented approach
Class detector
Attribute: status, location, neighbors
Operations: crate, sense-status, get location, find neighbors
Class alarm
Attributes: location, status
Operations: create, ring-alarm, get location, reset alarm
- In the object oriented program, an appropriate number of instance of the class detector and
alarm should be created.
- We can now examine the function oriented and the object oriented programs, and see that in
the function oriented program the system state is centralized and several functions on this
central data are defines.
- In case of the object oriented program, the state information is distributed among various
objects.

12
 MUTHAYAMMAL COLLEGE OF ARTS AND SCIENCE (AUTONOMOUS)
DEPARTMENT OF COMPUTER APPLICATION

Staff Name: [Link] Class: III BCA C Paper Code: 21M5UCAE01

Paper Name: SOFTWARE ENGINEERING Unit: III

UNIT-III
Function-Oriented Software Design: Overview of SA/SD methodology, structured analysis,
data flow diagrams (DFD’s), structured design, detailed design.
User-Interface design: Characteristics of a good interface; basic concepts; types of user
interfaces; component based GUI development, a user interface methodology.

Function-Oriented Software Design:

These techniques are currently being used in many software development organisations.
Overview of SA/SD Methodology:
SA/SD methodology involves carrying out two distinct activities:
1. Structured analysis (SA)
2. Structured design (SD)
The roles of structured analysis (SA) and structured design (SD) have been shown schematically in
figure.

 The structured analysis activity transforms the SRS document into a graphic model called the
DFD model.
 During structured analysis, functional decomposition of the system is achieved.
 The purpose of structured analysis is to capture the detailed structure of the system as
perceived by the user.

1
  The purpose of structured design is to define the structure of the solution that is suitable for
implementation in some programming language.
STRUCTURED ANALYSIS
During structured analysis, the major processing tasks (high-level functions) of the system are
analyzed, and the data flow among these processing tasks is represented graphically.
The structured analysis technique is based on the following underlying principles:
 Top-down decomposition approach.
 Application of divide and conquer principle.
 Through this each high level function is independently decomposed into detailed functions.
 Graphical representation of the analysis results using data flow diagrams (DFDs).
A DFD is a hierarchical graphical model of a system that shows the different processing activities or
functions that the system performs and the data interchange among those functions.
Data Flow Diagrams (DFDs)
 The DFD (also known as the bubble chart) is a simple graphical formalism.
 It can be used to represent a system in terms of the input data to the system, various
processing carried out on those data, and the output data generated by the system.
 The DFD technique is so popular because DFD is a very simple formalism— it is simple to
understand and use.
 A DFD model uses a very limited number of primitive symbols to represent the functions
performed by a system and the data flow among these functions.
 A DFD model only represents the data flow aspects and does not show the sequence of
execution of the different functions and the conditions based on which a function may or
may not be executed.
 In the DFD terminology, each function is called a process or a bubble.
 Each function as a processing station (or process) that consumes some input data and
produces some output data.
 DFD technique not only to represent the results of structured analysis but also useful for
several other applications.
 Starting with a set of high-level functions that a system performs, a DFD model represents
the subfunctions performed by the functions using a hierarchy of diagrams.

Primitive symbols used for constructing DFDs

There are essentially five different types of symbols used for constructing DFDs.

2
Function symbol: A function is represented using a circle. This symbol is called a process or a
bubble. Bubbles are annotated with the names of the corresponding functions
External entity symbol: It is represented by a rectangle. The external entities are essentially those
physical entities external to the software system which interact with the system by inputting data to
the system or by consuming the data produced by the system.
Data flow symbol: A directed arc (or an arrow) is used as a data flow symbol. A data flow symbol
represents the data flow occurring between two processes or between an external entity and a
process in the direction of the data flow arrow.
Data store symbol: A data store is represented using two parallel lines. It represents a logical file.
That is, a data store symbol can represent either a data structure or a physical file on disk.
Connected to a process by means of a data flow symbol. The direction of the data flow arrow shows
whether data is being read from or written into a data store.
Output symbol: The output symbol is used when a hard copy is produced.
Important concepts associated with constructing DFD models
Synchronous and asynchronous operations
 If two bubbles are directly connected by a data flow arrow, then they are synchronous.
 This means that they operate at the same speed.
 If two bubbles are connected through a data store then the speed of operation of the bubbles
are independent.

3
Data dictionary
 Every DFD model of a system must be accompanied by a data dictionary.
 A data dictionary lists all data items that appear in a DFD model.
 A data dictionary lists the purpose of all data items and the definition of all composite data
items in terms of their component data items.
 It includes all data flows and the contents of all data stores appearing on all the DFDs in a
DFD model.
 For the smallest units of data items, the data dictionary simply lists their name and their type.
Composite data items are expressed in terms of the component data items using certain
operators.
 The dictionary plays a very important role in any software development process, especially
for the following reasons:
o A data dictionary provides a standard terminology for all relevant data for use by the
developers working in a project.
o The data dictionary helps the developers to determine the definition of different data
structures in terms of their component elements while implementing the design.
o The data dictionary helps to perform impact analysis. That is, it is possible to
determine the effect of some data on various processing activities and vice versa.
 For large systems, the data dictionary can become extremely complex and voluminous.
 Computer-aided software engineering (CASE) tools come handy to overcome this problem.
 Most CASE tools usually capture the data items appearing in a DFD as the DFD is drawn,
and automatically generate the data dictionary.
Data definition
 Composite data items can be defined in terms of primitive data items using the following
data definition operators.

4
  +: denotes composition of two data items, e.g. a+b represents data a and b.
 [,,]: represents selection, i.e. any one of the data items listed inside the square bracket can
occur.
For example, [a,b] represents either a occurs or b occurs.
 (): the contents inside the bracket represent optional data which may or may not appear.
a+(b) represents either a or a+b occurs.
 {}: represents iterative data definition, e.g. {name}5 represents five name data.
 {name}* represents zero or more instances of name data.
 =: represents equivalence, e.g. a=b+c means that a is a composite data item comprising of
both b and c.
 /* */: Anything appearing within /* and */ is considered as comment.
Developing the DFD model of a system:
 The DFD model of a problem consists of many DFDs and a single data dictionary.
 The DFD model of a system is constructed by using a hierarchy of DFDs.
 The top level DFD is called the level 0 DFD or the context diagram.
○ It is the most abstract (simplest) representation of the system (highest level). It is the
easiest to draw and understand.
 At each successive lower level DFDs, more and more details are gradually introduced.
 To develop a higher-level DFD model, processes are decomposed into their sub processes
and the data flows among these subprocesses are identified.
 Level 0 and Level 1 consist of only one DFD each.
 Level 2 may contain up to 7 separate DFDs, and level 3 up to 49 DFDs, and so on.
 However, there is only a single data dictionary for the entire DFD model.
Context Diagram/Level 0 DFD:
 The context diagram is the most abstract (highest level) data flow representation of a system.
 It represents the entire system as a single bubble.
 The bubble in the context diagram is annotated with the name of the software system being
developed.
 The context diagram establishes the context in which the system operates; that is, who are
the users, what data do they input to the system, and what data they received by the system.
 The data input to the system and the data output from the system are represented as incoming
and outgoing arrows.

5
Level 1 DFD:
 The level 1 DFD usually contains three to seven bubbles.
 The system is represented as performing three to seven important functions.
 To develop the level 1 DFD, examine the high-level functional requirements in the SRS
document. If there are three to seven high level functional requirements, then each of these
can be directly represented as a bubble in the level 1 DFD.
 Next, examine the input data to these functions and the data output by these functions as
documented in the SRS document and represent them appropriately in the diagram.
Decomposition:
Each bubble in the DFD represents a function performed by the system.
The bubbles are decomposed into subfunctions at the successive levels of the DFD model.
Decomposition of a bubble is also known as factoring o r exploding a bubble.
Each bubble at any level of DFD is usually decomposed to anything from three to seven bubbles.
Decomposition of a bubble should be carried on until a level is reached at which the function of the
bubble can be described using a simple algorithm.
Developing a DFD model of a system
1. Construction of context diagram:
 Examine the SRS document to determine:
o Different high-level functions that the system needs to perform.
o Data input to every high-level function.
o Data output from every high-level function.
o Interactions (data flow) among the identified high-level functions.
 Represent these aspects of the high-level functions in a diagrammatic form.
 This would form the top-level data flow diagram (DFD), usually called the DFD 0.
2. Construction of level 1 diagram:
 Examine the high-level functions described in the SRS document.
 If there are three to seven high-level requirements in the SRS document, then represent each
of the high-level function in the form of a bubble.
 If there are more than seven bubbles, then some of them have to be combined.
 If there are less than three bubbles, then some of these have to be split.
3. Construction of lower-level diagrams:
 Decompose each high-level function into its constituent subfunctions through the following
set of activities:

6
 o Identify the different subfunctions of the high-level function.
o Identify the data input to each of these subfunctions.
o Identify the data output from each of these subfunctions.
o Identify the interactions (data flow) among these subfunctions.
 Represent these aspects in a diagrammatic form using a DFD.
 Recursively repeat Step 3 for each subfunction until a subfunction can be represented by
using a simple algorithm.
Numbering of bubbles
 The data that flow into or out of a bubble must match the data flow at the next level of DFD.
This is known as balancing a DFD.
 A DFD is required to be balanced with respect to the corresponding bubble of the parent
DFD.
 Balancing DFD is shown below:

 In the level 1 DFD, data items d1 and d3 flow out of the bubble 0.1 and the data item d2
flows into the bubble 0.1 (shown by the dotted circle).
 In the next level, bubble 0.1 is decomposed into three DFDs (0.1.1,0.1.2,0.1.3).
 The decomposition is balanced, as d1 and d3 flow out of the level 2 diagram and d2 flows in.
7
  Dangling arrows (d1,d2,d3) represent the data flows into or out of a diagram.
Shortcomings of the DFD model
[Link] DFDs leave ample scope to be imprecise.
 In the DFD model, the function performed by a bubble from its label.
 However, a short label may not capture the entire functionality of a bubble.
 For example, a bubble named find-book-position has only intuitive meaning and does not
specify several things, e.g. what happens when some input information is missing or is
incorrect.
 Further, the findbook-position bubble may not convey anything regarding what happens
when the required book is missing.
2. Not-well defined control aspects are not defined by a DFD.
 For instance, the order in which inputs are consumed and outputs are produced by a bubble is
not specified.
 A DFD model does not specify the order in which the different bubbles are executed.
 Representation of such aspects is very important for modelling real-time systems.
3. Decomposition:
 The method of carrying out decomposition to arrive at the successive levels and the ultimate
level to which decomposition is carried out are highly subjective and depend on the choice
and judgment of the analyst.
 Due to this reason, even for the same problem, several alternative DFD representations are
possible.
 Further, many times it is not possible to say which DFD representation is superior or
preferable to another one.
4. Improper data flow diagram:
 The data flow diagramming technique does not provide any specific guidance as to how
exactly to decompose a given function into its subfunctions and we have to use subjective
judgment to carry out decomposition.
Structured Design
 The aim of structured design is to transform the results of the structured analysis into a
structure chart.
 A structure chart represents the software architecture.

8
  The various modules making up the system, the module dependency (i.e. which module calls
which other modules), and the parameters that are passed among the different modules.
 The structure chart representation can be easily implemented using some programming
language.
 The basic building blocks using which structure charts are designed are as following:
Rectangular boxes:
A rectangular box represents a module.
Module invocation arrows:
An arrow connecting two modules implies that during program execution control is passed
from one module to the other in the direction of the connecting arrow.
Data flow arrows: These are small arrows appearing alongside the module invocation
arrows. It represents the fact that the named data passes from one module to the other in the
direction of the arrow.
Library modules: A library module is usually represented by a rectangle with double edges.
Libraries comprise the frequently called modules.
Selection: The diamond symbol represents the fact that one module of several modules
connected with the diamond symbol is invoked depending on the outcome of the condition
attached with the diamond symbol.
Repetition:
A loop around the control flow arrows denotes that the respective modules are invoked
repeatedly.
● In any structure chart, there should be one and only one module at the top, called the root.
● There should be at most one control relationship between any two modules in the structure
chart. This means that if module A invokes module B, module B cannot invoke module A.
Flow Chart vs Structure chart:
 Flow chart is a convenient technique to represent the flow of control in a program.
 A structure chart differs from a flow chart in three principal ways:
1. It is usually difficult to identify the different modules of a program from its flow chart
representation.
2. Data interchange among different modules is not represented in a flow chart.
3. Sequential ordering of tasks that is inherent to a flow chart is suppressed in a structure
chart.

9
Transformation of a DFD Model into Structure Chart:
 Systematic techniques are available to transform the DFD representation of a problem into a
module structure represented as a structure chart.
 Structured design provides two strategies to guide transformation of a DFD into a structure
chart:
○ Transform analysis ○ Transaction analysis
 At each level of transformation, it is important to first determine whether the transform or
the transaction analysis is applicable to a particular DFD.
Transform Analysis:
 Transform analysis identifies the primary functional components (modules) and the input
and output data for these components.
 The first step in transform analysis is to divide the DFD into three types of parts:
○ Input (afferent branch) ○ Processing (central transform) ○ Output (efferent branch)
 In the next step of transform analysis, the structure chart is derived by drawing one
functional component each for the central transform, the afferent and efferent branches.
 These are drawn below a root module, which would invoke these modules.
 In the third step of transform analysis, the structure chart is refined by adding sub functions
required by each of the high-level functional components.
Transaction Analysis:
 Transaction analysis is an alternative to transform analysis and is useful while designing
transaction processing programs.
 A transaction allows the user to perform some specific type of work by using the software.
 For example, ‘issue book’, ‘return book’, ‘query book’, etc., are transactions.
 As in transform analysis, first all data entering into the DFD need to be identified.
 In a transaction-driven system, different data items may pass through different computation
paths through the DFD.
 This is in contrast to a transform centered system where each data item entering the DFD
goes through the same processing steps.
 Each different way in which input data is processed is a transaction.
 For each identified transaction, trace the input data to the output.
 All the traversed bubbles belong to the transaction.
 These bubbles should be mapped to the same module on the structure chart.

10
  In the structure chart, draw a root module and below this module draw each identified
transaction as a module.
Detailed Design:
 During detailed design the pseudo code description of the processing and the different data
structures are designed for the different modules of the structure chart.
 These are usually described in the form of module specifications (MSPEC).
 MSPEC is usually written using structured English.
 The MSPEC for the non-leaf modules describe the different conditions under which the
responsibilities are delegated to the lower level modules.
 The MSPEC for the leaf-level modules should describe in algorithmic form how the
primitive processing steps are carried out.
 To develop the MSPEC of a module, it is usually necessary to refer to the DFD model and
the SRS document to determine the functionality of the module.
Design Review:
 After a design is complete, the design is required to be reviewed.
 The review team usually consists of members with design, implementation, testing, and
maintenance perspectives.
 The review team checks the design documents especially for the following aspects:
○ Traceability: Whether each bubble of the DFD can be traced to some module in the structure
chart and vice versa.
○ Correctness: Whether all the algorithms and data structures of the detailed design are correct.
○ Maintainability: Whether the design can be easily maintained in future.
○ Implementation: Whether the design can be easily and efficiently implemented.
 After the points raised by the reviewers are addressed by the designers, the design document
becomes ready for implementation.
User Interface Design
● The user interface portion of a software product is responsible for all interactions with the user.
Almost every software product has a user interface.
● User interface part of a software product is responsible for all interactions.
● The user interface part of any software product is of direct concern to the end-users.
● Many users often judge a software product based on its user interface
● An interface that is difficult to use leads to higher levels of user errors and ultimately leads to user
dissatisfaction.

11
● Sufficient care and attention should be paid to the design of the user interface of any software
product.
● Systematic development of the user interface is also important.
● Development of a good user interface usually takes a significant portion of the total system
development effort.
● For many interactive applications, as much as 50 per cent of the total development effort is spent
on developing the user interface part.
● Unless the user interface is designed and developed in a systematic manner, the total effort
required to develop the interface will increase tremendously.
Characteristics of a good User Interface
 The different characteristics that are usually desired of a good user interface. Unless we
know what exactly is expected of a good user interface, we cannot possibly design one.
Speed of learning:
 A good user interface should be easy to learn.
 A good user interface should not require its users to memorize commands.
 Neither should the user be asked to remember information from one screen to another
 The following three issues are crucial to enhance the speed of learning:
[Link] of metaphors and intuitive command names: Speed of learning an interface is greatly
facilitated if these are based on some day to-day real-life examples or some physical objects with
which the users are familiar with. The abstractions of real-life objects or concepts used in user
interface design are called metaphors.
[Link]: Once a user learns about a command, he should be able to use the similar commands
in different circumstances for carrying out similar actions.
[Link]-based interface: Users can learn an interface faster if the interaction style of the
interface is very similar to the interface of other applications with which the user is already familiar
with.
 The speed of learning characteristic of a user interface can be determined by measuring the
training time and practice that users require before they can effectively use the software.
Speed of use:
 Speed of use of a user interface is determined by the time and user effort necessary to initiate
and execute different commands.
 It indicates how fast the users can perform their intended tasks.

12
  The time and user effort necessary to initiate and execute different commands should be
minimal.
 This can be achieved through careful design of the interface.
 The most frequently used commands should have the smallest length or be available at the
top of a menu.
Speed of recall:
 Once users learn how to use an interface, the speed with which they can recall the command
issue procedure should be maximized.
 This characteristic is very important for intermittent users.
 Speed of recall is improved if the interface is based on some metaphors, symbolic command
issue procedures, and intuitive command names.
Error prevention:
 A good user interface should minimize the scope of committing errors while initiating
different commands.
 The error rate of an interface can be easily determined by monitoring the errors committed
by an average user while using the interface.
 The interface should prevent the user from entering wrong values.
Aesthetic and attractive:
 A good user interface should be attractive to use.
 An attractive user interface catches user attention and fancy.
 In this respect, graphics-based user interfaces have a definite advantage over text-based
interfaces.
Consistency:
 The commands supported by a user interface should be consistent.
 The basic purpose of consistency is to allow users to generalize the knowledge about aspects
of the interface from one part to another.
Feedback:
 A good user interface must provide feedback to various user actions.
 Especially, if any user request takes more than a few seconds to process, the user should be
informed about the state of the processing of his request.
 In the absence of any response from the computer for a long time, a novice user might even
start recovery/shutdown procedures in panic.

13
Support for multiple skill levels:
 A good user interface should support multiple levels of sophistication of command issue
procedure for different categories of users. ○
 This is necessary because users with different levels of experience in using an application
prefer different types of user interfaces.
Experienced users are more concerned about the efficiency of the command issue procedure,
whereas novice users pay importance to usability aspects.
The skill level of users improves as they keep using a software product and they look for
commands to suit their skill levels.
Error recovery (undo facility):
 While issuing commands, even the expert users can commit errors.
 Therefore, a good user interface should allow a user to undo a mistake committed by him
while using the interface.
 Users are inconvenienced if they cannot recover from the errors they commit while using a
software. If the users cannot recover even from very simple types of errors, they feel
irritated, helpless, and out of control.
User guidance and on-line help:
 Users seek guidance and on-line help when they either forget a command or are unaware of
some features of the software.
 Whenever users need guidance or seek help from the system, they should be provided with
appropriate guidance and help.
Basic Concepts:
User Guidance and Online help
 Users may seek help about the operation of the software any time while using the software.
This is provided by the on-line help system.
1. Online help system:
● Users expect the on-line help messages to be tailored to the context in which they invoke the “help
system”.
● Therefore, a good online help system should keep track of what a user is doing while invoking the
help system and provide the output message in a context-dependent way.

14
2. Guidance messages:
● The guidance messages should be carefully designed to prompt the user about the next actions he
might pursue, the current status of the system, the progress so far made in processing his last
command, etc.
● A good guidance system should have different levels of sophistication.
3. Error Messages:
● Error messages are generated by a system either when the user commits some error or when some
errors encountered by the system during processing due to some exceptional conditions, such as out
of memory, communication link broken, etc.
● Users do not like error messages that are either ambiguous or too general such as “invalid input or
system error”. Error messages should be polite.
Mode-based and modeless interfaces:
● A mode is a state or collection of states in which only a subset of all user interaction tasks can be
performed.
In a modeless interface, the same set of commands can be invoked at any time during the running of
the software.
● Thus, a modeless interface has only a single mode and all the commands are available all the time
during the operation of the software.
● On the other hand, in a mode-based interface, different sets of commands can be invoked
depending on the mode in which the system is.
● A mode-based interface can be represented using a state transition diagram.
Graphical User Interface versus Text-based User Interface:
● In a GUI multiple windows with different information can simultaneously be displayed on the
user screen. User has the flexibility to simultaneously interact with several related items at any time
● Iconic information representation and symbolic information manipulation is possible in a GUI.
● A GUI usually supports command selection using an attractive and user-friendly menu selection
system.
● In a GUI, a pointing device such as a mouse or a light pen can be used for issuing commands.
● A GUI requires special terminals with graphics capabilities for running and also requires special
input devices such a mouse.
● A text-based user interface can be implemented even on a cheap alphanumeric display terminal. ●
Graphics terminals are usually much more expensive than alphanumeric terminals, They have
become affordable.

15
Types of User Interfaces:
● User interfaces can be classified into the following three categories:
○ Command language-based interfaces. ○ Menu-based interfaces. ○ Direct manipulation interfaces.
● Each of these categories of interfaces has its own characteristic advantages and disadvantages.
Command Language-based Interface
● A command language-based interface—as the name itself suggests, is based on designing a
command language which the user can use to issue the commands.
● The user is expected to frame the appropriate commands in the language and type them
appropriately whenever required.
● A simple command language-based interface might simply assign unique names to the different
commands.
● However, a more sophisticated command language-based interface may allow users to compose
complex commands by using a set of primitive commands.
● The command language interface allows for the most efficient command issue procedure requiring
minimal typing.
● A command language-based interface can be implemented even on cheap alphanumeric terminals.
● A command language-based interface is easier to develop compared to a menu-based or a direct-
manipulation interface because compiler writing techniques are well developed
● command language-based interfaces suffer from several drawbacks.
● command language-based interfaces are difficult to learn and require the user to memorize the set
of primitive commands.
● Most users make errors while formulating commands.
● All interactions with the system are through a key-board and cannot take advantage of effective
interaction devices such as a mouse.
Issues in designing a command language based interface:
● The designer has to decide what mnemonics (command names) to use for the different commands.
● The designer has to decide whether the users will be allowed to redefine the command names to
suit their own preferences.
● The designer has to decide whether it should be possible to compose primitive commands to form
more complex commands.
Menu-Based Interfaces:
● An important advantage of a menu-based interface over a command language-based interface is
that a menu-based interface does not require the users to remember the exact syntax of the
commands.
16
● A menu-based interface is based on recognition of the command names, rather than recollection.
● In a menu-based interface the typing effort is minimal.
● A major challenge in the design of a menu-based interface is to structure a large number of menu
choices into manageable forms.
● Techniques available to structure a large number of menu items:
○ Scrolling menu:
■ Sometimes the full choice list is large and cannot be displayed within the menu area,
scrolling of the menu items is required.
■ In a scrolling menu all the commands should be highly correlated, so that the user can
easily locate a command that he needs.
■ This is important since the user cannot see all the commands at any one time.
○ Walking menu:
■ Walking menu is very commonly used to structure a large collection of menu items.
■ When a menu item is selected, it causes further menu items to be displayed adjacent to it in
a sub-menu.
■ A walking menu can successfully be used to structure commands only if there are tens
rather than hundreds of choices.
○ Hierarchical menu:
■ This type of menu is suitable for small screens with limited display area such as that in
mobile phones.
■ The menu items are organized in a hierarchy or tree structure.
■ Selecting a menu item causes the current menu display to be replaced by an appropriate
sub-menu.
COMPONENT-BASED GUI DEVELOPMENT
Window System
 Most modern graphical user interfaces are developed using some window system.
 A window system can generate displays through a set of windows.
Window:
 A window is a rectangular area on the screen.
 A window can be considered to be a virtual screen, in the sense that it provides an interface
to the user for carrying out independent activities, e.g., one window can be used for editing a
program and another for drawing pictures, etc.
 A basic window with its different parts is shown in Figure

17
  A window can be divided into two parts—client part, and non-client part.
 The client area makes up the whole of the window, except for the borders and scroll bars.
 The client area is the area available to a client application for display.
 The non-client-part of the window determines the look and feel of the window.
 The look and feel defines a basic behaviour for all windows, such as creating, moving,
resizing, iconifying of the windows.
 The window manager is responsible for managing and maintaining the non-client area of a
window.
Window management system (WMS)
 A graphical user interface typically consists of a large number of windows.
 Most graphical user interface development environments do this through a window
management system (WMS).
 A window management system is primarily a resource manager.
 It keeps track of the screen are a resource and allocates it to the different windows that seek
to use the screen.
 WMS can be considered as a user interface management system (UIMS) —which not only
does resource management, but also provides the basic behaviour to the windows and
provides several utility routines to the application programmer for user interface
development.
 A WMS simplifies the task of a GUI designer to a great extent by providing the basic
behaviour to the various windows such as move, resize, iconify, etc.

18
  They are created and by providing the basic routines to manipulate the windows from the
application program such as creating, destroying, changing different attributes of the
windows, and drawing text, lines, etc.
 A WMS consists of two parts as shown in figure:
1. a window manager, and 2 a window system.

Window manager and window system:

 The window manager is built on the top of the window system makes use of various services
provided by the window system.
 The window manager and not the window system determines how the windows look and
behave.
 Several kinds of window managers can be developed based on the same window system.
 The window manager can be considered as a special kind of client that makes use of the
services (function calls) supported by the window system.
 The application programmer can also directly invoke the services of the window system to
develop the user interface. The relationship between the window manager, window system,
and the application program is shown in Figure. T
 his figure shows that the end-user can either interact with the application itself or with the
window manager (resize, move, etc.) and both the application and the window manger
invoke services of the window manager.

19
Component-based development
 A development style based on widgets is called component-based (or widget-based ) GUI
development style.
 There are several important advantages of using a widget-based design style.
 One of the most important reasons to use widgets as building blocks is because they help
users learn an interface fast.
 In this style of development, the user interfaces for different applications are built from the
same basic components.
 Therefore, the user can extend his knowledge of the behaviour of the standard components
from one application to the other.
 Also, the component-based user interface development style reduces the application
programmer’s work significantly as he is more of a user interface component integrator than
a programmer in the traditional sense.
Some of these popular widgets are
Visual programming
 Visual programming is the drag and drop style of program development.
 In this style of user interface development, a number of visual objects (icons) representing
the GUI components are provided by the programming environment.
 The application programmer can easily develop the user interface by dragging the required
component types (e.g., menu, forms, etc.) from the displayed icons and placing them
wherever required.
 Thus, visual programming can be considered as program development through manipulation
of several visual objects.
 Reuse of program components in the form of visual objects is an important aspect of this
style of programming.
 Though popular for user interface development, this style of programming can be used for
other applications such as Computer-Aided Design application (e.g., factory design),
simulation, etc.
 User interface development using a visual programming language greatly reduces the effort
required to develop the interface.
 Examples of popular visual programming languages are Visual Basic, Visual C++, etc.
Visual C++ provides tools for building programs with windowbased user interfaces for
Microsoft Windows environments.

20
  In visual C++ we can design menu bars, icons, and dialog boxes, etc. before adding them to
our program.
 These objects are called as resources.
 We can design shape, location, type, and size of the dialog boxes before writing any C++
code for the application.
Types of Widgets
 Different interface programming packages support different widget sets.
 Some of them have similar kinds of widgets, so that one can think of a generic widget set
which is applicable to most interfaces.
 The following widgets we have chosen as representatives of this generic class.
Label widget:
 This is one of the simplest widgets.
 A label widget does nothing except to display a label, i.e., it does not have any other
interaction capabilities and is not sensitive to mouse clicks.
 A label widget is often used as a part of other widgets.
Container widget:
 These widgets do not stand by themselves, but exist merely to contain other widgets.
 Other widgets are created as children of the container widget.
 When the container widget is moved or resized, its children widget also get moved or
resized.
 A container widget has no callback routines associated with it.
Pop-up menu:
 These are transient and task specific.
 A pop-up menu appears upon pressing the mouse button, irrespective of the mouse position.
Pull-down menu:
 These are more permanent and general.
 We have to move the cursor to a specific location and pull down this type of menu.
Dialog boxes:
 We often need to select multiple elements from a selection list.
 A dialog box remains visible until explicitly dismissed by the user. A dialog box can include
areas for entering text as well as values.
 If an apply command is supported in a dialog box, the newly entered values can be tried
without dismissing the box.
21
Push button:
 A push button contains key words or pictures that describe the action that is triggered when
we activate the button.
 Usually, the action related to a push button occurs immediately when you click a push button
unless it contains an ellipsis (. . . ).
 A push button with an ellipsis generally indicates that another dialog box will appear.
Radio buttons:
 A set of radio buttons are used when only one option has to be selected out of many options.
 A radio button is a hollow circle followed by text describing the option it stands for.
 When a radio button is selected, it appears filled and the previously selected radio button
from the group is unselected.
 Only one radio button from a group can be selected at any time.
 This operation is similar to that of the band selection buttons that were available in old radios
Combo boxes:
 A combo box looks like a button until the user interacts with it.
 When the user presses or clicks it, the combo box displays a menu of items to choose from.
 A combo box is used to display either one-of-many choices when space is limited, the
number of choices is large, or when the menu items are computed at run-time.
An Overview of X-Window/MOTIF
 X-window system allows development of portable GUIs.
 Applications developed using the X-window system are device independent.
 Also, applications developed using the X-window system become network independent
 Network-independent GUI operation has been schematically represented in Figure.

22
  Here, A is the computer application in which the application is running.
 B can be any computer on the network from where we can interact with the application.
 Network independent GUI was pioneered by the X-window system in the mid-eighties at
MIT (Massachusetts Institute of Technology) with support from DEC (Digital Equipment
Corporation).
 Now-a-days many user interface development systems support network-independent GUI
development, e.g., the AWT and Swing components of Java.
 The X-window functions are low level functions written in C language which can be called
from application programs.
 But only the very serious application designer would program directly using the X-windows
library routines.
 Built on top of X-windows are higher level functions collectively called Xtoolkit, which
consists of a set of basic widgets and a set of routines to manipulate these widgets.
 One of the most widely used widget sets is X/Motif. Digital Equipment Corporation (DEC)
used the basic X-window functions to develop its own look and feel for interface designs
called DECWindows.
X Architecture
 The X architecture is pictorially depicted in Figure.

 The different terms used in this diagram are explained as follows:

23
X server:
 The X server runs on the hardware to which the display and the key board are attached.
 The X server performs low-level graphics, manages window, and user input functions.
 The X server controls accesses to a bit-mapped graphics display resource and manages it.
X protocol.
 The X protocol defines the format of the requests between client applications and display
servers over the network.
 The X protocol is designed to be independent of hardware, operating systems, underlying
network protocol, and the programming language used.
 X library (Xlib). The Xlib provides a set of about 300 utility routines for applications to call.
 These routines convert procedure calls into requests that are transmitted to the server.
 Xlib provides low level primitives for developing an user interface, such as displaying a
window, drawing characters and graphics on the window, waiting for specific events, etc.
Xtoolkit (Xt).
 The Xtoolkit consists of two parts: the intrinsics and the widgets.
 Widgets are predefined user interface components such as scroll bars, menu bars, push
buttons, etc. for designing GUIs.
 Intrinsics are a set of about a dozen library routines that allow a programmer to combine a
set of widgets into a user interface.
 In order to develop a user interface, the designer has to put together the set of components
(widgets) he needs, and then he needs to define the characteristics (called resources) and
behaviour of these widgets by using the intrinsic routines to complete the development of the
interface.
 Therefore, developing an interface using Xtoolkit is much easier than developing the same
interface using only X library.
Size Measurement of a Component-based GUI
 Lines of code (LOC) is not an appropriate metric to estimate and measure the size of a
component-based GUI.
 This is because, the interface is developed by integrating several pre- built components.
 The different components making up an interface might have been in written using code of
drastically different sizes.
 The effort of the GUI developer who develops an interface by integrating the components
may not be affected by the code size of the components he integrates.
24
  A way to measure the size of a modern user interface is widget points (wp).
 The size of a user interface (in wp units) is simply the total number of widgets used in the
interface. The size of an interface in wp units is a measure of the intricacy of the interface
and is more or less independent of the implementation environment.
 The wp measure opens up chances for contracts on a measured amount of user interface
functionality, instead of a vague definition of a complete system.
 An alternate way to compute the size of GUI is to simply count the number of screens.
 It is inaccurate since a screen complexity can range from very simple to very complex.
User Interface Design Methodology
A GUI Design Methodology:
● The GUI design methodology we present here is based on the seminal work of Frank Ludolph.
● Our user interface design methodology consists of the following important steps:
○ Examine the use case model of the software.
○ Interview, discuss, and review the GUI issues with the end-users.
○ Task and object modeling.
○ Metaphor selection.
○ Interaction design and rough layout.
○ Detailed presentation and graphics design.
○ GUI construction.
○ Usability evaluation.
Examining the use case model
● The starting point for GUI design is the use case model.
● This captures the important tasks the users need to perform using the software.
● Metaphors help in interface development at lower effort and reduced costs for training the users.
● Metaphors can also be based on physical objects such as a visitor’s book, a catalog, a pen, a brush,
a scissor, etc.
● A solution based on metaphors is easily understood by the users, reducing learning time and
training costs.
Task and object Modeling:
● A task is a human activity intended to achieve some goals.
● Examples of task goals can be as follows:
○ Reserve an airline seat
○ Buy an item Transfer money from one account to another

25
 ○ Book a cargo for transmission to an address.
● A task model is an abstract model of the structure of a task.
● A task model should show the structure of the subtasks that the user needs to perform to achieve
the overall task goal.
● Each task can be modeled as a hierarchy of subtasks.
● A task model can be drawn using a graphical notation similar to the activity network model.
● A user object model is a model of business objects which the end-users believe that they are
interacting with.
● The objects in a library software may be books, journals, members, etc.
Metaphor selection:
● The first place one should look for while trying to identify the candidate metaphors is the set of
parallels to objects, tasks, and terminologies of the use cases.
● If no obvious metaphors can be found, then the designer can fall back on the metaphors of the
physical world of concrete objects.
● The appropriateness of each candidate metaphor should be tested by restating the objects and tasks
of the user interface model in terms of the metaphor.
Interaction design and rough layout.
● The interaction design involves mapping the subtasks into appropriate controls, and other widgets
such as forms, text box, etc.
● This involves making a choice from a set of available components that would best suit the
subtask.
● Rough layout concerns how the controls, and other widgets to be organized in windows.
Detailed presentation and graphics design
● Each window should represent either an object or many objects that have a clear relationship to
each other.
● At one extreme, each object view could be in its own window. But, this is likely to lead to too
much window opening, closing, moving, and resizing.
● At the other extreme, all the views could be placed in one window side-by-side, resulting in a very
large window.
● This would force the user to move the cursor around the window to look for different objects.
GUI construction
● Some of the windows have to be defined as modal dialogs.
● When a window is a modal dialog, no other windows in the application are accessible until the
current window is closed.
26
● When a modal dialog is closed, the user is returned to the window from which the modal dialog
was invoked.
● Modal dialogs are commonly used when an explicit confirmation or authorisation step is required
for an action.
User interface inspection
● Nielson studied common usability problems and built a check list of points which can be easily
checked for an interface.
The following checklist is based on the work of Nielson:
○ Visibility of the system status
○ Match between the system and the real world
○ Undoing mistakes
○ Consistency
○ Recognition rather than recall
○ Support for multiple skill levels
○ Aesthetic and minimalist design
○ Help and error messages
○ Error prevention

27
 MUTHAYAMMAL COLLEGE OF ARTS AND SCIENCE (AUTONOMOUS)
DEPARTMENT OF COMPUTER APPLICATION

Staff Name: [Link] Class: III BCA C Paper Code: 21M5UCAE01

Paper Name: SOFTWARE ENGINEERING Unit: IV

Unit – IV
Coding and Testing : Coding – Code Review – Testing – Unit Testing – Black Box Testing –
White Box Testing – Debugging – Program Analysis Tools – Integration Testing – System Testing.
Software Reliability and Quality Management : Software Reliability – Statistical Testing –
Software Quality – Software Quality Management System – ISO 9000 – SEI Capability Maturity
Model.
[Link] AND TESTING
- Coding is undertaken once the design phase is complete and the design documents
have been successfully reviewed.
In the coding phase, every module specified in the design document is coded and unit
tested. During unit testing, each module is tested in isolation from other modules.
- After all the modules of a system have been coded and unit tested, the integration
and system testing phase is undertaken.
During each integration step, a number of modules are added to the partially
integrated system and the resultant system is tested. The full product takes shape only after
all the modules have been integrated together. System testing is conducted on the full
product. During system testing, the product is tested against its requirements as recorded in
the SRS document.
[Link]
- The input to the coding phase is the design document produced at the end of
the design phase.
- The objective of the coding phase is to transform the design of a system into code in a
high-level language, and then to unit test this code.
- Good software development organizations normally require their programmers to adhere to
some well-defined and standard style of coding called coding standards.
- Most software development organizations formulate their own coding standards that suit
them most, and require their engineers to follow these standards rigorously.
- The purpose of requiring all engineers of an organization to adhere to a standard style of
coding is the following:
 A coding standard gives a uniform appearance to the codes written by different
engineers.
 It enhances code understanding.
 It encourages good programming practices. A coding standard lists several rules to
be followed during coding, such as the way variables are to be named, the way the
code is to be laid out, error return conventions, etc.
1
Coding standards and guidelines
- Good software development organizations usually develop their own coding standards and
guidelines depending on what best suits their organization and the type of products they
develop.
- The following are some representative coding standards.
Rules for limiting the use of global
- These rules list what types of data can be declared global and what cannot.
Standard headers for different modules:
- The information contained in the headers of different modules should be standard for an
organization. The exact format in which the header information is organized in the header
can also be specified. The following are some standard header data:
 Name of the module.
 Date on which the module was created.
 Author’s name.
 Modification history.
 Synopsis of the module.
 Different functions supported, along with their input/output parameters.
 Global variables accessed/modified by the module.
Naming conventions for global variables, local variables, and constant Identifiers:
- A possible naming convention can be that global variable names always start with a capital
letter, local variable names are made of small letters, and constant names are always capital
letters.
Error returns conventions and exception handling mechanisms:
- The way error conditions are reported by different functions in a program are handled should
be standard within an organization. For example, different functions while encountering an
error condition should either return a 0 or 1 consistently. The following are some
representative coding guidelines recommended by many software development organizations.
Do not use a coding style that is too clever or too difficult to understand:
- Code should be easy to understand. Many inexperienced engineers actually take pride in
writing cryptic and incomprehensible code. Clever coding can obscure meaning of the code
and hamper understanding. It also makes maintenance difficult.
Avoid obscure side effects:
- The side effects of a function call include modification of parameters passed by reference,
modification of global variables, and I/O operations. An obscure side effect is one that is not
obvious from casual examination of the code. Obscure side effects make it difficult to
understand a piece of code. For example, if a global variable is changed obscurely in a called
module or some file I/O is performed which is difficult to infer from the function’s name and
header information, it becomes difficult for anybody trying to understand the code.
Length of any function should not exceed 10 source lines:
- A lengthyfunction is usually very difficult to understand as it probably has a large number of
variables and carries out many different types of computations. For the same reason, lengthy
functions are likely to have disproportionately larger number of bugs.
Do not use GO TO statements
2
 - Use of GO TO statements makes a program unstructured. This makes the program very
difficult to understand, debug, and maintain.

[Link] REVIEW

- Code review for a model is carried out after the module is successfully compiled and the all
the syntax errors have been eliminated.
- Code reviews are extremely cost-effective strategies for reduction in coding errors and to
produce high quality code. Normally, two types of reviews are carried out on the code of a
module.
- These two types of code review techniques are code inspection and code walkthrough.

Code walkthrough: The main objective of code walkthrough is to discover the algorithmic and
logical errors in the code. In this technique, a module is taken up for review after the module has
been coded, successfully compiled, and all syntax errors have been eliminated.
Code Inspection: The principal aim of code inspection is to check for the presence of some
common types of errors that usually creep into code due to programmer mistakes and oversights and
to check whether coding standards have been adhered to.

Following is a list of some classical programming errors which can be checked during code
inspection:
 Use of uninitialized variables.
 Jumps into loops.
 Non terminating loops.
 Incompatible assignments.
 Array indices out of bounds.
 Improper storage allocation and deallocation
 Mismatches between actual and formal parameter in procedure calls.
 Use of incorrect logical operators or incorrect precedence among operators.
 Improper modification of loop variables.
 Comparison of equally of floating point variables, etc

[Link]

 Testing a program involves executing the program with a set of test inputs and observing if
the program behaves as expected. If the program fails to behave as expected, then the input
data and theconditions under which it fails are noted for later debugging and error correction.
A highly simplified view of program testing is schematically shown

3
Some commonly used terms associated with testing are:
Failure: This is a manifestation of an error (or defect or bug). But, the mere presence of an error may
not necessarily lead to a failure.
Test case: This is the triplet [I,S,O], where I is the data input to the system, S is the state of the
system at which the data is input, and O is the expected output of the system.
Test suite: This is the set of all test cases with which a given software product is to be tested.

Verification versus Validation

 The objectives of both verification and validation techniques are very similar since both
these techniques are designed to help remove errors in a software.
 Verification is the process of determining whether the output of one phase of software
development conforms to that of its previous phase; whereas validation is the process of
determining whether a fully developed software conforms to its requirements specification.
 Thus, the objective of verification is to check if the work products produced after a phase
conform to that which was input to the phase.
 For example, a verification step can be to check if the design documents produced after the
design step conform to the requirements specification.
 On the other hand, validation is applied to the fully developed and integrated software to
check if it satisfies the customer’s requirements.
 Verification does not require execution of the software, whereas validation requires
execution of the software.
 Verification is carried out during the development process to check if the development
activities are proceeding alright, whereas validation is carried out to check if the right as
required by the customer has been developed.
 While verification is concerned with phase containment of errors, the aim of validation
is to check whether the deliverable software is error free.
 Based on the above discussions, we can conclude that:
Error detection techniques = Verification techniques + Validation techniques

Testing Activities

Testing involves performing the following main activities:

 Test suite design: The set of test cases using which a program is to be tested is designed
possibly using several test case design techniques
 Running test cases and checking the results to detect failures: Each test case is run and
the results are compared with the expected results. A mismatch between the actual result and
expected results indicates a failure. The test cases for which the system fails are noted down
for later debugging.
 Locate error: In this activity, the failure symptoms are analysed to locate the errors. For
each failure observed during the previous activity, the statements that are in error are
identified.
 Error correction: After the error is located during debugging, the code is appropriately
changed to correct the error.
 The testing activities have been shown schematically in Figure below. As can be seen, the
test cases are first designed, the test cases are run to detect failures. The bugs causing the
failure are identified through debugging, and the identified error is corrected. Of all the
above mentioned testing activities, debugging often turns out to be the most time-consuming
activity.
4
There are essentially two main approaches to systematically design test cases:
1. Black-box approach
2. White-box (or glass-box) approach

 In the black-box approach, test cases are designed using only the functional specification of
the software. That is, test cases are designed solely based on an analysis of the input/out
behaviour (that is, functional behaviour) and does not require any knowledge of the internal
structure of a program. For this reason, black-box testing is also known as functional testing.
 On the other hand, designing white-box test cases requires a thorough knowledge of the
internal structure of a program, and therefore white-box testing is also called structural
testing.
 Black- box test cases are designed solely based on the input-output behaviour of a program.
In contrast, white-box test cases are based on an analysis of the code.
 These two approaches to test case design are complementary. That is, a program has to be
tested using the test cases designed by both the approaches, and one testing using one
approach does not substitute testing using the other.

[Link] in the Large versus Testing in the Small

A software product is normally tested in three levels or stages:
o Unit testing
o Integration testing
o System testing
 During unit testing, the individual functions (or units) of a program are tested.
 Unit testing is referred to as testing in the small, whereas integration and system
testing are referred to as testing in the large.
 After testing all the units individually, the units are slowly integrated and tested after each
step of integration (integration testing).
 Finally, the fully integrated system is tested (system testing). Integration and system testing
are known as testing in the large.

[Link] TESTING

5
 Unit testing is undertaken after a module has been coded and reviewed. This activity is
typically undertaken by the coder of the module himself in the coding phase. we first discuss the
environment needed to perform unit testing.

Driver and stub modules

In order to test a single module, we need a complete environment to provide all relevant code
that is necessary for execution of the module. That is, besides the module under test, the following
are needed to test the module:
 The procedures belonging to other modules that the module under test calls.
 Non-local data structures that the module accesses.
 A procedure to call the functions of the module under test with appropriate parameters.
Modules required to provide the necessary environment (which either call or are called by the
module under test) are usually not available until they too have been unit tested.
In this context, stubs and drivers are designed to provide the complete environment for a module
so that testing can be carried out.

Stub: The role of stub and driver modules is pictorially shown in Figure. A stub procedure is a
dummy procedure that has the same I/O parameters as the function called by the unit under test but
has a highly simplified behaviour. For example, a stub procedure may produce the expected
behaviour using a simple table look up mechanism.

Figure : Unit testing with the help of driver and stub modules.

Driver: A driver module should contain the non-local data structures accessed by the module under
test. Additionally, it should also have the code to call the different functions of the unit under test
with appropriate parameter values for testing.

[Link] BOX TESTING

- Black Box Testing treats an application as a black box and only looks at the outputs that are
produced by specific inputs into the application.
- The black box tester does not need to understand why the code does what it does, and they
should not have access to the source code of the application.
- Requirements are used to determine the correct outputs of black box testing, and these test
cases are used to validate that the right software is being built, i.e. that the application does
what the requirements say.

6
 - Black box testing checks that required functionality exists and is correct, the interface works
properly, data structures behind the interface work properly, the behavior and performance
of the system are within proper bounds, and that the initialization and termination of the
program are correct. Integration, functional and system, acceptance, beta, and regression
testing all are forms of black box tests.
- A minimal black box test suite should have one test case for every requirement of the
application.
- To optimize testing beyond this minimal set of tests equivalence partitioning, boundary value
analysis, decision tables, and diabolical test cases should be created.
- Equivalence partitioning divides the set of possible input values into equivalence classes.
Only a value from each of the equivalence classes needs to be tested.

- Boundary value analysis looks at testing around a set boundary. A test case should be made
for the boundary value, n, n-1, and n+1.
- Boundary value analysis-based test suite design involves designing test cases using the
values at the boundaries of different equivalence classes.
- Decision tables looks at all decision points in the program and looks at the results of all
decision paths in the scenario. Finally, diabolic tests investigate extreme use of the
application.
- We now summarise the important steps in the black-box test suite design approach:
o Examine the input and output values of the program.
o Identify the equivalence classes.
o Design equivalence class test cases by picking one representative value from each
equivalence class.
o Design the boundary value test cases as follows. Examine if any equivalence class is
a range of values.
o Include the values at the boundaries of such equivalence classes in the test suite.

[Link] BOX TESTING

- White Box Testing is tests that are run an application with the knowledge of the internal
working of the code base.
- White box testing is used in three of the six basic types of testing: unit, integration, and
regression testing.

7
 - Unit testing is done on a small piece, or unit, of code. This unit is usually a class. When a
unit is integrated into the main code base, it is more difficult to find a bug in that unit.
- Integration testing looks at how all components of an application interact. White box
integration tests specifically look at the interfaces between the components.
- Regression testing verifies that modifications to the system have not damaged the whole of
the system. Unit tests and integration tests can be rerun in regression testing to verify that
modifications to the application work properly.
- White box test cases should test different paths, decision points (both true and false
decisions), execute loops, and check internal data structures of the application.
- Basis path testing, equivalence partitioning, and boundary value analysis are all used to
create white box tests. Basis path testing looks at the decision points in the application.
- Equivalence partitioning divides the set of possible input values into equivalence classes.
Only a value from each of the equivalence classes needs to be tested. Boundary value
analysis looks at testing around a set boundary. A test case should be made for the boundary
value, n, n-1, and n+1.
- The goal of white box testing is to cover testing as many of the statements, decision point,
and branches in the code base as possible.

[Link]
- Debugging is defined as a process of analyzing and removing the error. It is considered
necessary in most of the newly-developed software or hardware and in commercial
products/personal application programs. For complex products, debugging is done at all the
levels of the testing.
The Debugging Process
- During debugging, errors are encountered that range from less damaging to catastrophic. The
various levels of errors increase, the amount of effort to find their causes also increases. One
error are identified in a software system, to debug the Problem, the following steps are used.
1. Defect confirmation/identification
- A problem is identified in a system and a defect report is created. A software
engineer maintains and analysis this error report and finds solution to the following
questions.
 What is the expected/desired behavior of the system?
 What is the actual behavior Brute force?
 Does a defect exist in the system?
2. Defect analysis
-If the defect is genuine, the next step is to understand the root cause of the problem.
Generally, engineers debug by starting a debugging tool and they try to understand
the root cause of the problem by the following a step-by-step execution of the
program.
3. Defect resolution
-Once the root cause of a problem is identified, the error can be resolved by making
an appropriate change to the system by fixing the problem.
-After the debugging process ends, the software is retested to ensure that no errors are
left undetected. Moreover, it checks that no new errors are left undetected. Moreover,
8
 it checks that no new errors are introduced in the software as a result of change made
to it during the debugging process.
The Debugging Approaches
Popular Debugging approaches are

[Link] force method

This is the most common method of debugging but is the least efficient method. In this
approach, print statements are inserted throughout the program to print the intermediate values with
the hope that some of the printed values will help to identify the statement in error. This approach
becomes more systematic with the use of a symbolic debugger (also called a source code debugger ),
because values of different variables can be easily checked and break points and watch points can be
easily set to test the values of variables effortlessly. Single stepping using a symbolic debugger is
another form of this approach, where the developer mentally computes the expected result after
every source instruction and checks whether the same is computed by single stepping through the
program.

[Link]
` This is also a fairly common approach. In this approach, starting from the statement at which
an error symptom has been observed, the source code is traced backwards until the error is
discovered. Unfortunately, as the number of source lines to be traced back increases, the number of
potential backward paths increases and may become unmanageably large for complex programs,
limiting the use of this approach.

[Link] elimination method

In this approach, once a failure is observed, the symptoms of the failure (i.e., certain variable
is having a negative value though it should be positive, etc.) are noted. Based on the failure
symptoms, the causes which could possibly have contributed to the symptom is developed and tests
are conducted to eliminate each. A related technique of identification of the error from the error
symptom is the software fault tree analysis.

[Link] slicing
This technique is similar to back tracking. In the backtracking approach, one often has to
examine a large number of statements. However, the search space is reduced by defining slices. A
slice of a program for a particular variable and at a particular statement is the set of source lines
preceding this statement that can influence the value of that variable. Program slicing makes use of
the fact that an error in the value of a variable can be caused by the statements on which it is data
dependent.

Debugging Guidelines

Debugging is often carried out by programmers based on their ingenuity and experience. The
following are some general guidelines for effective debugging:
 Many times debugging requires a thorough understanding of the program design. Trying to
debug based on a partial understanding of the program design may require an inordinate
amount of effort to be put into debugging even for simple problems.
 Debugging may sometimes even require full redesign of the system. In such cases, a
common mistakes that novice programmers often make is attempting not to fix the error but
its symptoms.
 One must be beware of the possibility that an error correction may introduce new errors.
Therefore after every round of error-fixing, regression testing must be carried out.
9
[Link] ANALYSIS TOOLS
Static Analysis Tools
o Static program analysis (also static code analysis or SCA) is the analysis of computer
software that is performed without actually executing programs built from that
software (analysis performed on executing programs is known as dynamic analysis).
o In most cases the analysis is performed on some version of the source code and in the
other cases some form of the object code.
o The term is usually applied to the analysis performed by an automated tool, with
human analysis being called program understanding, program comprehension or code
review.
Dynamic Analysis Tools
o Dynamic program analysis is the analysis of computer software that is performed by
executing programs built from that software system on a real or virtual processor.
o For dynamic program analysis to be effective, the target program must be executed
with sufficient test inputs to produce interesting behavior. Use of software
testing techniques such as code coverage helps ensure that an adequate slice of the
program's set of possible behaviors has been observed.
o Also, care must be taken to minimize the effect that instrumentation has on the
execution (including temporal properties) of the target program.

4.1.10. INTEGRATION TESTING

- Integration testing is the phase in software testing in which individual software modules are
combined and tested as a group.
- It occurs after unit testing and before validation testing.
- Integration testing takes as its input modules that have been unit tested, groups them in larger
aggregates, applies tests defined in an integration test plan to those aggregates, and delivers
as its output the integrated system ready for system testing.
- The objective of integration testing is to check whether the different modules of a
program interface with each other properly.
- During integration testing, different modules of a system are integrated
 Big Bang approach
 Top down approach
 Bottom up approach
 Mixed approach
Big Bang
- The Big Bang method is very effective for saving time in the integration testing process.
However, if the test cases and their results are not recorded properly, the entire integration
process will be more complicated and may prevent the testing team from achieving the goal
of integration testing.

Bottom Up Testing

10
 - This is an approach to integrated testing where the lowest level components are tested first,
then used to facilitate the testing of higher level components. The process is repeated until
the component at the top of the hierarchy is tested.
- All the bottom or low-level modules, procedures or functions are integrated and then tested.
After the integration testing of lower level integrated modules, the next level of modules will
be formed and can be used for integration testing.
- This approach is helpful only when all or most of the modules of the same development level
are ready. This method also helps to determine the levels of software developed and makes it
easier to report testing progress in the form of a percentage.

Top Down Testing

- This is an approach to integrated testing where the top integrated modules are tested and the
branch of the module is tested step by step until the end of the related module.

Mixed Approach Testing

- This is an approach to combine top down testing with bottom up testing.
- The main advantage of the Bottom-Up approach is that bugs are more easily found. With
Top-Down, it is easier to find a missing branch link

[Link] TESTING

- After all the units of a program have been integrated together and tested, system testing is
taken up.
- System tests are designed to validate a fully developed system to assure that it meets
its requirements. The test cases are therefore designed solely based on the SRS
document.
- The system testing procedures are the same for both object-oriented and procedural
programs, since system test cases are designed solely based on the SRS document and the
actual implementation (procedural or object oriented) is immaterial.
There are essentially three main kinds of system testing depending on who carries out testing:
1. Alpha Testing: Alpha testing refers to the system testing carried out by the test team within the
developing organization.
2. Beta Testing: Beta testing is the system testing performed by a select group of friendly customers.
3. Acceptance Testing: Acceptance testing is the system testing performed by the customer to
determine whether to accept the delivery of the system.
In each of the above types of system tests, the test cases can be the same, but the difference
is with respect to who designs test cases and carries out testing.
 The system test cases can be classified into functionality and performance test cases.
Before a fully integrated system is accepted for system testing, smoke testing is performed.
 Smoke testing is done to check whether at least the main functionalities of the software are
working properly. Unless the software is stable and at least the main functionalities are
working satisfactorily, system testing is not undertaken. The functionality tests are designed
to check whether the software satisfies the functional requirements as documented in the
SRS document.
 The performance tests, on the other hand, test the conformance of the system with the non-
functional requirements of the system. We have already discussed how to design the
functionality test cases by using a black-box approach. All performance tests can be
considered as black-box tests.
11
  Several types of performance testing are
1. Stress Testing
2. Volume Testing
3. Configuration Testing
4. Compatibility Testing
5. Regression Testing
6. Recovery Testing
7. Maintenance Testing
8. Documentation Testing
9. Usability Testing
10. Security Testing

4.2. SOFTWARE RELIABILITY AND QUALITY MANAGEMENT

Reliability of a software product is an important concern for most users. Users not only want
the products they purchase to be highly reliable, but for certain categories of products they may even
require a quantitative guarantee on the reliability of the product before making their buying decision.
This may especially be true for safety-critical and embedded software products.
The success of a project does not depend on who exactly are the team members of the project.
Besides, the quality of the developed software and the cost of development are important issues
addressed by SQA.

4.2.1. SOFTWARE RELIABILITY

The reliability of a software product essentially denotes its trustworthiness or dependability.
Alternatively, the reliability of a software product can also be defined as the probability of the
product working “correctly” over a given period of time.
Based on some discussions, we can summarize the main reasons that make software
reliability more difficult to measure than hardware reliability:
 The reliability improvement due to fixing a single bug depends on where the bug is located
in the code.
 The perceived reliability of a software product is observer-dependent.
 The reliability of a product keeps changing as errors are detected and fixed.

[Link] Hardware versus Software Reliability

 Hardware components fail due to very different reasons as compared to software
components. Hardware components fail mostly due to wear and tear, whereas software
components fail due to bugs.

12
[Link]. 11.1.2 RELIABILITY METRICS OF SOFTWARE PRODUCTS
The reliability requirements for different categories of software products may be different.
For this reason, it is necessary that the level of reliability required for a software product should be
specified in the software requirements specification (SRS) document. In order to be able to do this,
we need some metrics to quantitatively express the reliability of a software product. A good
reliability measure should be observer-independent, so that different people can agree on the degree
of reliability a system has. However, in practice, it is very difficult to formulate a metric using
which precise reliability measurement would be possible. In the absence of such measures, we
discuss six metrics that correlate with reliability as follows:
 Rate of occurrence of failure (ROCOF): ROCOF measures the frequency of
occurrence of failures. ROCOF measure of a software product can be obtained by
observing the behaviour of a software product in operation over a specified time interval
and then calculating the ROCOF value as the ratio of the total number of failures
observed and the duration of observation. However, many software products do not run
continuously (unlike a car or a mixer), but deliver certain service when a demand is
placed on them. For example, library software is idle until a book issue request is made.
Therefore, for a typical software product such as a pay-roll software, applicability of
ROCOF is very limited.
 Mean time to failure (MTTF): MTTF is the time between two successive failures,
averaged over a large number of failures. To measure MTTF, we can record the failure
data for n failures. Let the failures occur at the time instants t1, t2, ..., tn. Then, MTTF
can be calculated as

.
o It is important to note that only run time is considered in the time measurements.
That is, the time for which the system is down to fix the error, the boot time, etc. are
not taken into account in the time measurements and the clock is stopped at these
times.
 Mean time to repair (MTTR): Once failure occurs, some time is required to fix the
error. MTTR measures the average time it takes to track the errors causing the failure and
to fix them.
 Mean time between failure (MTBF): The MTTF and MTTR metrics can be combined
to get the MTBF metric: MTBF=MTTF+MTTR. Thus, MTBF of 300 hours indicates
that once a failure occurs, the next failure is expected after 300 hours. In this case, the
time measurements are real time and not the execution time as in MTTF.
 Probability of failure on demand (POFOD): Unlike the other metrics discussed, this
metric does not explicitly involve time measurements. POFOD measures the likelihood
of the system failing when a service request is made.
o For example, a POFOD of 0.001 would mean that 1 out of every 1000 service
requests would result in a failure. We have already mentioned that the reliability of a
software product should be determined through specific service invocations, rather
than making the software run continuously. Thus, POFOD metric is very appropriate
for software products that are not required to run continuously.
 Availability: Availability of a system is a measure of how likely would the system be
available for use over a given period of time. This metric not only considers the number
of failures occurring during a time interval, but also takes into account the repair time
(down time) of a system when a failure occurs. This metric is important for systems such
13
 as telecommunication systems, and operating systems, and embedded controllers, etc.
which are supposed to be never down and where repair and restart time are significant
and loss of service during that time cannot be overlooked.

[Link].SHORTCOMINGS OF RELIABILITY METRICS OF SOFTWARE PRODUCTS

A scheme of classification of failures is as follows:
 Transient: Transient failures occur only for certain input values while invoking a
function of the system.
 Permanent: Permanent failures occur for all input values while invoking a function of
the system.
 Recoverable: When a recoverable failure occurs, the system can recover without having
to shutdown and restart the system (with or without operator intervention).
 Unrecoverable: In unrecoverable failures, the system may need to be restarted.
 Cosmetic: These classes of failures cause only minor irritations, and do not lead to
incorrect results. An example of a cosmetic failure is the situation where the mouse
button has to be clicked twice instead of once to invoke a given function through the
graphical user interface.

[Link] TESTING
 Statistical testing is a testing process whose objective is to determine the reliability of the
product rather than discovering errors. The test cases designed for statistical testing with an
entirely different objective from those of conventional testing.
 To carry out statistical testing, we need to first define the operation profile of the product.
 Operation profile: Different categories of users may use a software product for very
different purposes.
 For example, a librarian might use the Library Automation Software to create member
records, delete member records, add books to the library, etc., whereas a library member
might use software to query about the availability of a book, and to issue and return books.
 Formally, we can define the operation profile of software as the probability of a user
selecting the different functionalities of the software. If we denote the set of various
functionalities offered by the software by {fi}, the operational profile would associate with
each function {fi} with the probability with which an average user would select {fi} as his
next function to use.
 Thus, we can think of the operation profile as assigning a probability value pi to each
functionality fi of the software.

How to define the operation profile for a product?

We need to divide the input data into a number of input classes. For example, for a graphical
editor software, we might divide the input into data associated with the edit, print, and file
operations. We then need to assign a probability value to each input class; to signify the probability
for an input value from that class to be selected. The operation profile of a software product can be
determined by observing and analysing the usage pattern of the software by a number of users.

Steps in Statistical Testing

 The first step is to determine the operation profile of the software.
 The next step is to generate a set of test data corresponding to the determined operation
profile.

14
  The third step is to apply the test cases to the software and record the time between each
failure. After a statistically significant number of failures have been observed, the reliability
can be computed.
 For accurate results, statistical testing requires some fundamental assumptions to be satisfied.
It requires a statistically significant number of test cases to be used.
 It further requires that a small percentage of test inputs that are likely to cause system failure
to be included.
 Now let us discuss the implications of these assumptions. It is straight forward to generate
test cases for the common types of inputs, since one can easily write a test case generator
program which can automatically generate these test cases.
 However, it is also required that a statistically significant percentage of the unlikely inputs
should also be included in the test suite. Creating these unlikely inputs using a test case
generator is very difficult.

Pros and cons of statistical testing

Statistical testing allows one to concentrate on testing parts of the system that are most likely
to be used. Therefore, it results in a system that the users can find to be more reliable (than actually
it is!). Also, the reliability estimation arrived by using statistical testing is more accurate compared
to those of other methods discussed. However, it is not easy to perform the statistical testing
satisfactorily due to the following two reasons. There is no simple and repeatable way of defining
operation profiles. Also, the the number of test cases with which the system is to be tested should be
statistically significant.

4.2.3. SOFTWARE QUALITY

The modern view of a quality associates with a software product several quality factors (or attributes)
such as the following:
 Portability: A software product is said to be portable, if it can be easily made to work in
different hardware and operating system environments, and easily interface with external
hardware devices and software products.
 Usability: A software product has good usability, if different categories of users (i.e., both
expert and novice users) can easily invoke the functions of the product.
 Reusability: A software product has good reusability, if different modules of the product
can easily be reused to develop new products.
 Correctness: A software product is correct, if different requirements as specified in the SRS
document have been correctly implemented.
 Maintainability: A software product is maintainable, if errors can be easily corrected as and
when they show up, new functions can be easily added to the product, and the functionalities
of the product can be easily modified, etc.

4.2.4. SOFTWARE QUALITY MANAGEMENT SYSTEM

 A quality management system (often referred to as quality system) is the principal
methodology used by organizations to ensure that the products they develop have the
desired quality.
 A quality system is the responsibility of the organization as a whole. However, every
organization has a separate quality department to perform several quality system
activities. The quality system of an organization should have the full support of the top
management. Without support for the quality system at a high level in a company, few
members of staff will take the quality system seriously.

15
Quality System Activities

The quality system activities encompass the following:

 Auditing of projects to check if the processes are being followed.
 Collect process and product metrics and analyze them to check if quality goals are being met.
 Review of the quality system to make it more effective.
 Development of standards, procedures, and guidelines.
 Produce reports for the top management summarizing the effectiveness of the quality system
in the organization.
A good quality system must be well documented. Without a properly documented quality system,
the application of quality controls and procedures become ad hoc, resulting in large variations in the
quality of the products delivered. Also, an undocumented quality system sends clear messages to the
staff about the attitude of the organization towards quality assurance. International standards such as
ISO 9000 provide guidance on how to organize a quality system.
 Quality control (QC) focuses not only on detecting the defective products and eliminating
them, but also on determining the causes behind the defects, so that the product rejection rate
can be reduced.

 Thus, quality control aims at correcting the causes of errors and not just rejecting the
defective products. The next breakthrough in quality systems, was the development of the
quality assurance (QA) principles.
 The basic premise of modern quality assurance is that if an organization’s processes are good
and are followed rigorously, then the products are bound to be of good quality.
 The modern quality assurance paradigm includes guidance for recognizing, defining,
analyzing, and improving the production process. Total quality management (TQM)
advocates that the process followed by an organization must continuously be improved
through process measurements.

Product Metrics Versus Process Metrics

 Product metrics help measure the characteristics of a product being developed, whereas
process metrics help measure how a process is performing.
 Examples of product metrics are LOC and function point to measure size, PM (person-
month) to measure the effort required to develop it, months to measure the time required
to develop the product, time complexity of the algorithms, etc. Examples of process
metrics are review effectiveness, average number of defects found per hour of inspection,
average defect correction time, productivity, average number of failures detected during
testing per LOC, number of latent defects per line of code in the developed product.

[Link] CAPABILITY MATURITY MODEL

16
  S E I capability maturity model (SEI CMM) was proposed by Software Engineering Institute
of the Carnegie Mellon University, USA.
 CMM is patterned after the pioneering work of Philip Crosby who published his maturity
grid of five evolutionary stages in adopting quality practices.
 CMM is a reference model for appraising the software process maturity into different levels.
This can be used to predict the most likely outcome to be expected from the next project that
the organization undertakes.
 It must be remembered that SEI CMM can be used in two ways - capability evaluation and
software process assessment.
 Capability evaluation and software process assessment differ in motivation, objective, and
the final use of the result.
 Capability evaluation provides a way to assess the software process capability of an
organisation. Capability evaluation is administered by the contract awarding authority, and
therefore the results would indicate the likely contractor performance if the contractor is
awarded a work.
 On the other hand, software process assessment is used by an organisation with the objective
to improve its own process capability.
 SEI CMM classifies software development industries into the following five maturity levels:
1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimising
1. Initial
Software development organisation at this level is characterised by adhoc activities. Very few or
no processes are defined and followed. Since software production processes are not defined,
different engineers follow their own process and as a result development efforts become chaotic.
Therefore, it is also called chaotic level.

2. Repeatable
At this level, the basic project management practices such as tracking cost and schedule are
established. Configuration management tools are used on items identified for configuration control.
Size and cost estimation techniques such as function point analysis, COCOMO, etc., are used. The
necessary process discipline is in place to repeat earlier success on projects with similar applications.

3. Defined
At this level, the processes for both management and development activities are defined and
documented.

4. Managed
At this level, the focus is on software metrics. Both process and product metrics are collected.
The process metrics are used to check if a project performed satisfactorily. Thus, the results of
process measurements are used to evaluate project performance rather than improve the process.

5. Optimising
At this stage, process and product metrics are collected. Process and product measurement data
are analysed for continuous process improvement.

17
 Focus areas of CMM levels and Key Process Areas

CMM Shortcomings
CMM does suffer from several shortcomings. The important among these are the following:
 The most frequent complaint by organisations while trying out the CMM-based process
improvement initiative is that they understand what is needed to be improved, but they need
more guidance about how to improve it.
 Another shortcoming (that is common to ISO 9000) is that thicker documents, more detailed
information, and longer meetings are considered to be better. This is in contrast to the
principles of software economics—reducing complexity and keeping the documentation to
the minimum without sacrificing the relevant details.
 Getting an accurate measure of an organisation’s current maturity level is also an issue. The
CMM takes an activity-based approach to measuring maturity; if you do the prescribed set of
activities then you are at a certain level. There is nothing that characterises or quantifies
whether you do these activities well enough to deliver the intended results.

[Link].7.2 Personal Software Process (PSP)

 PSP is based on the work of David Humphrey . PSP is a scaled down version of industrial
software process. PSP is suitable for individual use. It is important to note that SEI CMM
does not tell software developers how to analyse, design, code, test, or document software
products, but assumes that engineers use effective personal practices. PSP recognises that the
process for individual use is different from that necessary for a team.
 The quality and productivity of an engineer is to a great extent dependent on his process.
PSP is a framework that helps engineers to measure and improve the way they work. It helps
in developing personal skills and methods by estimating, planning, and tracking performance
against plans, and provides a defined process which can be tuned by individuals.
 Time measurement: PSP advocates that developers should rack the way they spend time.
Because, boring activities seem longer than actual and interesting activities seem short.
Therefore, the actual time spent on a task should be measured with the help of a stop-watch
to get an objective picture of the time spent. For example, he may stop the clock when
attending a telephone call, taking a coffee break, etc. An engineer should measure the
time he spends for various development activities such as designing, writing code, testing,
etc.
 PSP Planning: Individuals must plan their project. Unless an individual properly plans his
activities, disproportionately high effort may be spent on trivial activities and important
18
 activities may be compromised, leading to poor quality results. The developers must estimate
the maximum, minimum, and the average LOC required for the product. They should use
their productivity in minutes/LOC to calculate the maximum, minimum, and the average
development time. They must record the plan data in a project plan summary.
 The PSP is schematically shown in Figure While carrying out the different phases, an
individual must record the log data using time measurement. During post-mortem, they can
compare the log data with their project plan to achieve better planning in the future projects,
to improve his process, etc.

Figure : A schematic representation of PSP.

 The PSP levels are summarised in Figure. PSP2 introduces defect management via the use of
checklists for code and design reviews. The checklists are developed by analysing the defect
data gathered from earlier projects.

19
20