SOFTWARE ENGINEERING

III YEAR – VI SEMESTER

COURSE CODE: 7BCE6C3

CORE COURSE-XIV–SOFTWARE ENGINEERING

Unit I
Introduction: Introduction to software engineering – some definitions –
some size factors –quality and productivity factors – managerial issuesPlanning
a software project: Defining the problem– developing a solution strategy –
planning the development process – planning an organizational structure – other
planning activities
Unit II
Software Cost Estimation: software cost factors – software cost
estimation techniques –estimating software maintenance costs
Software Requirements Definition: The software requirements
specification – formal specification techniques
Unit III
Software Design: Fundamental design concepts – modules and
modularization criteria – design notations – design techniques – Stepwise
refinement – Integrated top down development – Jackson Structured
Programming -detailed design considerations –test plan – milestones,
walkthroughs and inspections – design guidelines
Unit IV
Software Implementation: Structured coding techniques – coding style –
standards and guidelines - Verification and validation techniques – Quality
Assurance – Walkthrough and inspection -Unit Testing and Debugging –
System Testing
Unit V
Software Maintenance: Enhancing maintainability during development –
managerial aspects of software engineering – configuration management –
source code metrics – other maintenance tools and techniques

Text Book:

1. Software Engineering Concepts – Richard E. Fairley, Tata McGraw Hill

Publishing Company Ltd, New Delhi

Page 1
 SOFTWARE ENGINEERING

UNIT-I
INTRODUCTION

Develops a software product

 User needs and constraints stated
 Product must accommodate implementers, users and maintainers
 Source code tested
 Maintenance, user manual, installation instructions, training aids
and maintenance of documents must be prepared
 Software maintenance- change requests, redesign and modification
of source code through testing of the modified code
 Appropriate user sites

Software products- 1960

Ex: airline, train, medical and other general purpose

Definition

Software Engineering is the technical and management discipline concerned

with systematic production and maintenance of software products that are
developed and modified on time within cost estimates.

Programmers- Implementing, packaging and modifying algorithms.

Software engineers- analysis design, verification and validation, testing,

documentation, software maintenance and project management.

SIZE FACTORS

1. Total effort devoted to software:

•1955- Hardware cost 80% high
•1980- Reverse

Page 2
 SOFTWARE ENGINEERING

2. Distribution of Effort
 1 to 3 years development and 15 years maintenance
 The distribution effort 40/60, 30/70, 10/90

Page 3
 SOFTWARE ENGINEERING

3. Project Size Categories

Determines the level of management control and the types of tools and
techniques required on a software project.

Trivial: One programmer working part time, develop the software for the
exclusive use of the programmer and one usually discarded after a few months.
Small projects: Scientific application written by engineers to solve numerical
problems.
Medium Size projects: Assemblers, Compliers, Small management Systems,
inventory, process control applications.
Large Projects : Large compilers, time-sharing systems, data base packages,
graphics programs for data acquisition and display.
Very large projects: air traffic control, missile, defence and military command
and control systems

4. How programmers spend their time:

Writing programs 18%
Reading programs and manuals 16%
Job communication 32%
Personal 13%

Page 4
 SOFTWARE ENGINEERING

Miscellaneous 15%
Training 6%
Mail 5%

QUALITY AND PRODUCTIVITY FACTORS

Writing small programs for personal use and developing or modifying a
software product.

Ex: Electrical engineer assembling the components

High quality software Technical and managerial skill

Factors that influence quality and productivity

1. Individual level:

Lack of Competence Poor productivity and quality

General Competence of individual Ability to
Two Aspects write correct programs
Familiarity of the individual

Page 5
 SOFTWARE ENGINEERING

Experiment by Sackman
12 programmers implemented 2 programs

Performance measure Ratio

Debugging hours #1 28:1
Debugging hours #2 26:1
Runtime #1 5:1
Runtime #2 13:1

2. Team Communication
 Many programmers low social needs prefer to work alone
 Increased product size results in decreasing programmer
 Brooks- number of paths among the programmers is n(n-1)/2 n= number
of programmers If n=3 3(3-1)/2=6/2=3

3. Product Complexity:
Three level of product complexity.

Application programs written in HLL Scientific and data processing

Highest productivity measured in lines of productivity

Utility programs Compilers, assemblers, linkage editors, loaders

HLL
(Pascal, Ada, Assembly language)

5 to 10 times(effort)

System level programs Data Communication packages

PL/1 or Ada

25 to 100 times effort

Page 6
 SOFTWARE ENGINEERING

4. Appropriate Notations:
Good notations clarify the relationships

Vehicle of communication among the project personnel

5. Systematic approaches
 use accepted procedures and techniques

6. Change Control
 Software adapts general purpose computing hardware to particular
applications

7. Level of Technology
 Hardware and software facilities available for developing, using and
maintain a software product.
 Modern programming practices include use of systematic analysis and
design techniques, appropriate notations, structured coding, systematic
techniques for examining design documents and source code.

8. Level of Reliability:
 Basic level of reliability
 Extreme Reliability – Great care in analysis, design, implementation,
system testing and maintenance of software product.
9. Problem Understanding:
 Not understanding problem leads to limitations
 Careful planning, customer interviews, task observation, user manual,
product specifications can increase both customers and developer
understands the problem.
10. Available time
 Six programmer effort can be completed in 6 months or six programmers
in one month.
11. Required skills
 Good communication skills, writing text book-no misspellings.
 No errors in syntax or punctuation.
 Absolute consistency in cross referencing.
15. Appropriate goals:
software product should provide, generality, efficiency, reliability.

Page 7
 SOFTWARE ENGINEERING

MANAGERIAL ISSUES
 Managerial activities:
 Managers have responsibility for ensuring that software products are
delivered on time and within cost estimates.
 Developing business plans, recruiting customers, developing marketing
strategies and recruiting and training employees.
 Important management problems
 Planning for software engineering projects is generally poor.
 Procedures and techniques for the selection of project managers are poor.
 Responsibilities for various project functions.
 Ability to accurately estimate the resources.
 Success criteria of projects are frequently inappropriate.

 Aid in selecting the proper organizational structure are not available.

 Procedures, methods, and techniques for designing a project control
system are not readily available.
 Standards and techniques for measuring the quality of performance of
production expected from the programmers are not available.

Solution to solve above mentioned problems

 Educate and train top management, project managers and software
developers.
 Enforce the use of standards, procedures and documentation.
 Analyse data from prior software projects to determine effective methods.
 Define objectives in terms of quality desired.
 Define quality in terms of deliverables
 Establish success priority criteria
 Allow for contingencies
 Develop truthful, accurate cost and schedule estimates
 Select project managers based on ability to manage software projects,
rather than on technical ability or availability.
 Make specific work assignment to software developers and apply job
performance standards.

Page 8
 SOFTWARE ENGINEERING

PLANNING A SOFTWARE PROJECT

I. DEFINING THE PROBLEM

1. The problem statement should be phrased in the customer’s terminology
2. Justify a computerised solution strategy for the problem
3. Identify the functions to be provided – hardware and software subsystems
4. Determine system level goals and requirements
5. Establish high level acceptance criteria for the system

Developing a solution strategy

6. Outline several solution strategies, without regard for constraints
7. Conduct a feasibility study for each strategy
8. Recommend a solution strategy, indicating why other strategies were
rejected.
9. Develop a list of priorities for product characteristics
Planning the development process
10. Define a life-cycle model and an organizational structure for the project.
11. Plan the configuration management, quality assurance and validation
activities.
12. Determine phase-dependent tools, techniques and notations to be used.
13. Establish preliminary cost estimates for system development
14. Establish a preliminary development schedule
15. Establish preliminary staffing estimates
16. Preliminary estimates to operate and maintain the system
17. Prepare a glossary of terms
18. Identify sources of information, and refer to them throughout the project
plan.
A. GOALS AND REQUIREMENTS
 After identification of problem preliminary goals and requirements
formulated.
 Goals Targets of achievement

Goals
Qualitative Quantitative
System enhance the professional skill System should be delivered within 12
months
System should make users job The system should reduce the cost of a
interesting transaction by 25%

Page 9
 SOFTWARE ENGINEERING

 Some goals apply to every project and every product

 Software product should be reliable, useful, understandable and cost
effective
 Other goals ex: ease of use of nonprogrammers depend on the particular
situation

Requirements: System requirements

Functional requirements
Performance requirements
Requirements of hardware, firmware and software

Requirements
Quantified requirements Qualitative requirement
Phase accuracy shall be within 0.5 degrees Accuracy shall be sufficient to support mission

Response to external interrupts shall be 0.25 second System shall provide real-time response
maximum
System shall reside in 50k bytes of memory System shall make efficient use of primary memory

System shall be 99% reliable

High level goals expressed in terms of quality attributes

Software Quality characteristic tree

Page 10
 SOFTWARE ENGINEERING

II. DEVELOPING A SOLUTION STRATEGY

 Several strategies should be considered. One solution strategy must be

chosen by the planners to do feasibility study.
 Feasibility study examine the solution constraints
 Feasibility of a solution include
case studies
Worst case analysis

III. PLANNING THE DEVELOPING PROCESS

Software life cycle models

a. phased life-cycle model
b. prototype model/milestones, documents and reviews
c. Cost model
d. Successive versions model

a. Phased life-cycle model

Phased model segments software into successive activities

Phase Well-defined processes Well-defined products

Resources are required to complete each phase

Page 11
 SOFTWARE ENGINEERING

The phased model consists of the above phases.

The products cascade from one level to the next in smooth progression

Analyses two sub phases

 planning
 Requirement

a. understanding customer problem

b. perform feasibility study
c. Develop recommended strategy
d. Determine the acceptance criteria

System definition
Planning Project plan
Cost estimates and work schedules

 In English/some other languages

 Charts, figures, graphs, tables and equations
 Life cycle model is used
 Organizational structure of the project

Page 12
 SOFTWARE ENGINEERING

 Preliminary development schedule

 Preliminary cost
 Preliminary staff requirement
 Tools, techniques and standards

 Requirement Definition identifying the basic functions of

hardware, software and people system.

Architectural design: identifies the software components, decoupling and

decomposing them into processing modules and conceptual data structures and
specifying the interconnections among components.

Detailed design: is adaptation of existing code, modification of standard

algorithms, invention of new algorithms, data representations and packaging of
the software product.

Implementation phase : is translation of design specifications into source

code, debugging, documentation and unit testing of source code.

Errors in implementation phase – logical errors, errors in data structure

layout, failure to capture customer needs, design error that reflect that failure to
translate requirement into correct design.it is expensive to remove analysis and
design errors from source code.

System testing – integration testing and acceptance testing

Acceptance testing: involves planning and executing various types of tests in

order to demonstrate the implemented software system satisfies the
requirements stated in requirement document.
Software system is released for production work and enters the maintenance
phase of the life cycle model.

Maintenance activities
a. enhancement of capabilities
b. adaptation of software to new processing environment
c. correction of software bugs

Page 13
 SOFTWARE ENGINEERING

b. Milestones, documents and reviews

Page 14
 SOFTWARE ENGINEERING

The following reviews and milestones in the phased life-cycle model

1. System definition and project plan are prepared
2. User manual is prepared
3. Software requirement specification is prepared
4. Software verification plan is prepared
5. Software requirement review for all the 4 points above
6. Software design specification – architectural design, and detailed design
7. Software product specification
8. Detailed design- critical design review is held
9. Design phase- software verification plan in expanded to include methods that
will be used to verify that the design is complete and consistent.
10. Actual test plan includes, actual test cases and expected results and
capabilities to be demonstrated by each test.
11. During the implementation phase, source code is written, debugging unit
tested.
12. The user manual, installation and training plans and software maintenance
plane are completed during implementation phase.
13. Prior to product delivery, final acceptance review is performed.
14. Project legacy is written, what went wrong and what went well.

C. The Cost Model

 Cost of performing the various activities in a software project
 Cost- sum of cost incurred in conducting each phase of the project.

Page 15
 SOFTWARE ENGINEERING

 The system definition and project plan in the cost of performing the
planning and preparing the documents, cost of verifying the customer
needs.
 Software requirement specification includes the cost complete with
respect to the system definition and the customer needs.
 Cost of design activities and preparing the design specification and the
test plan, plus the cost of modifying the correcting the system definition,
project plan and software requirement specification.
 The cost of product implementation is cost of user manual, system
definition, project plan, software requirement specification, design
specification, verification plan plus the cost of verifying that the
implementation is correct, complete and consistent.
 Finally, the cost of software maintenance is the sum of the costs of
performing product enhancement, making adaptations to new processing
requirements and fixing bugs.

Page 16
 SOFTWARE ENGINEERING

d. The prototype life-cycle model

A prototype is a mock-up or model of a software product.

Reasons for developing a prototype:
 Illustrate input data formats, messages, reports and interactive dialogues
for the customer.
 Gaining better understanding of the customer needs
 Explore technical issues in the proposed product.
 Major design decision will depend on response time of the device
controller/efficiency of a sorting algorithm.
 In situations where analysis, design, implementation is not appropriate.
 The nature of prototyping to be performed on a particular software
depend on the nature of the product.

Page 17
 SOFTWARE ENGINEERING

e. Successive Versions

Product development by the method of successive versions is an extension of

prototyping in which an initial product skeleton is refined into increasing levels
of capability.

 Analysis phase followed by design, implementation, building and

assessment of successive versions.
 The dashed line indicates that the assessment of version I may dictate the
need for further analysis before designing version I+1.

Analysis and design followed by implementation of successive versions

 Version 1 through N of the product are designed prior to any

implementation activities. In this case the characteristics of each
successive design will have been planned during analysis phase.

Page 18
 SOFTWARE ENGINEERING

 Dashed line indicate the implementation of the 𝐼𝑡ℎversion may reveal the
need for further analysis and design before proceeding with
implementation of version 𝐼+1.

PLANNING AN ORGANIZATIONAL STRUCTURE

1. Planning structure
a. Project format
 Involves a team of programmers who conduct a project from start to
finish.
 Team members do project definition, design, implement, test, conduct

 Project reviews and prepare supporting documents.

 Some members may stay with product installation and maintenance.
 Typically work for 1 to 3 years are assigned new projects on completion
of the current one.
b. Functional Format
 A different team of programmers perform each phase of the project and
the work products pass from team to team as they evolve planning and
analysis team(system definition and plan)

Product definition team(s/w req. analysis and specification)

Implementation team(implements, debugs, unit test)

Quality Assessment team( certifies the quality)

Maintenance team

c. Matrix Format
 Each of the functions has its own management team and a group of
specialist personnel who are concerned only with that function.

Page 19
 SOFTWARE ENGINEERING

 Product function matrix organization, each functional group participates

in each project. For ex: software development team member belong
originally to the development function but work under supervision of a
particular project manager.
 disadvantage: more than one boss
 Matrix organizations are increasingly popular because special expertise
can be concentrated in particular functions.

2. Programming team structure

 Every programming team have an internal structure. The best team
structure for any particular project depends on the nature of the project
and the product.

Page 20
 SOFTWARE ENGINEERING

a. Democratic teams (egoless team)

 In egoless team goals are set and decisions made by group consensus.
Group leadership rotates from member to member based on the tasks to
be performed and the differing abilities of the team members.
 Democratic team differs from an egoless team

Advantages
 Opportunity to each team member to contribute to decisions
 Learn from one another
 Increased job satisfaction
Disadvantages
 All team members must work well together
 Weakening individual responsibility and authority

b. Chief programmer teams

Page 21
 SOFTWARE ENGINEERING

 Highly structured
 The work is allocated by the chief programmer
 The programmers between two and five, write code, debug, document
and unit test
 Librarian maintain program listings, design documents and test plans
 Back-up programmer serves as a consultant to the chief programmer on
various technical problems
 Liason with customer publications group quality assurance group
perform some analysis, design.

c. Hierarchical team structure

In a hierarchical team, the project leader assigns tasks, attends reviews and
walkthroughs, detects problem areas, balances the workload and participates in
technical activities.

 It limits the number of communication paths

 It is reasonable to have 3 teams in hierarchical fashion, with each team
leader reporting to the project leader.
 The number of immediate subordinates at each level should be limited to
five to seven people.

Page 22
 SOFTWARE ENGINEERING

d. Management by objectives(MBO)
 Using MBO, employees set their own goals and objectives with the help
of their supervisor, participate in the setting of their supervisors goals.
 Objectives are set for periods of 1 to 3 months
 MBO is well suited to the milestones and intermediate work products of
software engineering.

Other planning activities

1. Planning for configuration management and quality assurance
2. for independent verification and validation.
3. Planning phase-independent tools and techniques
4. Other planning activities cost estimates, schedule, preliminary staffing level.

Page 23
 SOFTWARE ENGINEERING

UNIT II
SOFTWARE COST ESTIMATION

SOFTWARE COST FACTORS

1. Programmer Ability

Experiment sackman and colleagues. The goal was to determine the relative
influence of batch and time-shared access on programmer’s productivity.

Ex: 12 programmers given 2 programmes each

11 years experience
productivity variation 16:1
Individual differences in ability can be significant.

2. Product complexity

3 categories of software product

Application programs
Utility programs
System programs

Brooks’s states that utility programs are 3 times as difficult to write as

application programs and that systems program and that system programs are 3
times as difficult to write utility programs
1(App)-3(utility)-9(System)

Boehm three levels

PM=programmer months
KDSI= number of thousands of delivered instructions

Application
PM=2.4*(KDSI)**1.05
Utility
PM=3.0*(KDSI)**1.12
System
PM=3.6*(KDSI)**1.20

Page 24
 SOFTWARE ENGINEERING

3. Product size:
A large software product is obviously more expensive to develop the
small one. Boehm’s equations indicate that the rate of increase in required effort
grows with the number of source instructions at an exponential rate slightly
greater than one.

4. Available time:
Total project effort is sensitive to the calendar time available for project
completion. Most of them agree that software projects require more total effort
if development time is compressed or expanded from the optimal time.

5. Required level of reliability

Software reliability can be defined as the probability that a program will
perform a required function under stated conditions for a stated period of time.
It can be expressed in terms of accuracy, robustness, completeness, consistency
of the source code.
Boehm describes five categories

Category Effect of failure

Very low Slight inconvenience
Low Losses easily recovered
Nominal Moderately difficult to recover losses
High High financial loss
Very high Risk to human life

6. Level of technology
Software development project is reflected by the programming language,
the abstract machine, the programming practices and software tools used. The
number of source instructions written per day is largely dependent of the
language used, written in HLL, expand into several machine level statements.

K. YUGASENTHILRAJA M.C.A., M.Phil, B.Ed.,

ASSISTANT PROFESSOR
Page 25
 SOFTWARE ENGINEERING

SOFTWARE COST ESTIMATION TECHNIQUES

Software cost estimates are based on past performance.

Historical data are used to identify cost factors and determine the relative
importance and various factors within the environment of that organization.
Cost estimates can be either top-down or bottom-up.
Top-down estimation first focuses on system-level costs(such as personal
required to develop the system)
Bottom-up cost estimation first estimates the cost of develop each module or
subsystem.

1. Expert judgement
The most widely used cost estimation technique is expert judgement, which is
an inherently top-down estimation technique.
Expert judgement relies on the experience background and business sense of
one or more key people in the organization.
Advantages
Experience can also be a liability.
The expert may be confident that the project is similar to a previous one, but
may have overlooked some factors that make the new project significantly
different.

2. Delphi cost estimation

Developed by Rand Corporation in 1948 to gain expert consensus without
introducing the adverse side effects.
Delphi technique can be adapted to software cost estimation in the following
manner.

Coordinator provides each estimator with the system definition document

with the system definition document and a form for recording a cost estimate.

They complete their estimates. They may ask questions of the co-ordinator but
they do not discuss their estimates with one another.
The coordinator prepared distributes a summary of the estimators, responses
and includes any unusual rationales, noted by the estimators.

Page 26
 SOFTWARE ENGINEERING

Estimators complete another estimate, using the results from the previous
estimate.
The process is iterated for as many rounds as required . No group discussion
is allowed during the entire process.

3. Work breakdown structure

The work break down chart can indicate either product hierarchy or process
hierarchy.
Product hierarchy identifies the product components and indicates the manner
in which the components and interconnected.
Process hierarchy identifies the work activities and relationship among
activities.

Product hierarchy

Some planners use both product and process hierarchy. Advantages

Work break down structure technique are identifying and accounting for
various process and product factors, and is making explicit exactly which costs
are included in the estimate.

Page 27
 SOFTWARE ENGINEERING

Process of work breakdown structure

4. Algorithmic cost models

Bottom-up estimators
Constructive cost model(COCOMO) is an algorithmic cost model described
by bohem
COCOMO effort multipliers
a. Product attributes
b. computer attributes
c. personal attributes
d. project attributes

Ex: normal organic mode equations apply in the following types of situations.
Small to medium size projects (2k to 32k) familiar applications area.
Stable, well-understood virtual machine in house development effort.

ESTIMATING SOFTWARE MAINTENANCE COSTS

 Labor costs: This includes the cost of the personnel who perform the
maintenance, such as software developers, engineers, and technicians.
Hardware and software costs: This includes the cost of hardware and
software tools used for maintenance, such as servers, software licenses, and
development tools.
 Training costs: This includes the cost of training personnel to perform
maintenance tasks, such as software developers, engineers, and technicians.
The effort of software maintenance can include:
 Time and resources: This includes the time and resources required to
perform the maintenance, such as the time required to identify and fix the
problem, test the solution, and implement the solution.
Communication and coordination: This includes the effort required to
communicate and coordinate with stakeholders, such as customers and
other teams.
Testing and validation: This includes the effort required to test and
validate the solution to ensure that it is working correctly and that it does
not cause any new problems.
The cost and effort of software maintenance can be reduced by:

Page 28
 SOFTWARE ENGINEERING

 Adopting a proactive maintenance strategy that includes regular testing,

monitoring, and updating of the system to prevent problems from occurring
Automating repetitive and routine tasks
Using modern development methodologies such as Agile, and Continuous
Integration and Continuous Deployment (CI/CD)
Using tools and technologies that can help to improve the efficiency of
maintenance tasks, such as automated testing tools and configuration
management tools
Having a clear and well-defined maintenance plan that includes regular
maintenance activities, such as testing, backup, and bug fixing.
It’s important to note that software maintenance is an ongoing process, and
the cost and effort of maintenance will vary over time as the system
evolves and new requirements are added.

Categories of Software Maintenance:

 Corrective Maintenance
 Adaptive Maintenance
 Perfective Maintenance
 Preventive Maintenance

The cost of system maintenance represents a large proportion of the budget of

most organizations that use software system. More than 65% of software
lifecycle cost is expanded in the maintenance activities.
Cost of software maintenance can be controlled by postponing the.
development opportunity of software maintenance but this will cause the
following intangible cost:
 Customer dissatisfaction when requests for repair or modification cannot be
addressed in a timely manner.
 Reduction in overall software quality as a result of changes that introduce
hidden errors in maintained software.

SOFTWARE REQUIREMENTS

• The process of establishing the services that the customer requires from a
system and the constraints under which it operates and is developed
• Requirements may be functional or non-functional
• Functional requirements describe system services or functions
• Non-functional requirements is a constraint on the system or on the
development process

Page 29
 SOFTWARE ENGINEERING

Types of requirements

• User requirements
• Statements in natural language (NL) plus diagrams of the services the
system Provides and its operational constraints. Written for customers

• System requirements
• A structured document setting out detailed descriptions
Written as a contract between client and contractor

• Software specification
• A detailed software description which can serve as a basis for a design
or implementation. Written for developers

THE SOFTWARE REQUIREMENT SPECIFICATION

Format of a software requirement specification

 Product overview and summary
 Development, operating and maintenance environments
 External interfaces and dataflow
 Functional requirements
 Performance requirements
 Exception handling
 Early subsets and implementation priorities
 Forseable modifications and enhancements
 Acceptance criteria
 Design hints and guidelines
 Cross reference index
 Glossary of terms

AN INFORMAL DFD

Page 30
 SOFTWARE ENGINEERING

Sec 1 and 2 elaboration of the software product characteristics contained in the

system definition and the preliminary user manual.

Sec 3 includes user displays, report formats, user commands, DFD , data
dictionary.

DFD specify data sources, data sinks, data stores, transformations to be

performed on the data and the flow of data between sources, sinks,
transformations and stores.

A formal DFD

Sources and data sinks shaded rectangles

Transformations ordinary rectangles

Data stores open ended rectangles

Page 31
 SOFTWARE ENGINEERING

Arcs data flow

ORDER PROCESSING

 The entries in a data dictionary include the name of the data item and
attributes such as the DFD, where it is used its purpose, where it is
derived from its sub items and any notes that may be appropriate.

Ex: data dictionary entry

Name : create
Where used :SDLP
Purpose : create passes- user created and design
Derived from : user interface processor
Subitems :name, uses, procedures , references
Notes : create contains one complete user-created design entity.

Sec 4: software requirement specification specifies the functional requirements

it is expressed in relational and state oriented notations.

Sec 5: response time activities, processing time for various processes,

throughput, pricing, secondary memory constraints.

Page 32
 SOFTWARE ENGINEERING

Sec 6: Exception handling : A table of exception conditions and exception

responses should be prepared. Ex: table overflow, array indices out of range,
runtime stack overflow etc.,

Sec7: Software developed as a series of successive versions. The initial version

may be skeletal prototype each successive user functions and provides
framework for evolution of the product.

Sec 8: foreseeable modifications and enhancement that may be incorporated in

the product following initial product release.

Sec 9: software product acceptance criteria are specified i.e functional and
performance test that must be performed, and the standards to be applied to the
source code.

Sec 10: contain design hints and guidelines

Sec 11: relates product requirements to the sources of information used in

Deriving the requirements verification and reexamination of requirements,
constraints and assumptions.

Sec 12: provides definition of terms that may be unfamiliar to the customer and
the product developers

FORMAL SPECIFICATION TECHNIQUES

1. Relational Notations:
a. Implicit equations: State the properties of a solution without stating a solution
method.

ex: Matrix inversion as M * M’ = I + E Error Matrix

Original Matrix Identity Matrix

Inverse Matrix

E- specifies allowable computable errors

Page 33
 SOFTWARE ENGINEERING

Ex: Square root function, SQRT

(0<=X<=Y)[ABS(SQRT(X)**2-X)<E]
for all real values of X in the closed range 0 to Y, computing the square root of
X, squaring it, subtract X, result in error value.

b. Recurrence Relations: The recurrence relation consists of an initial part

called the basis and one or more recursive parts.
Fibonacci numbers can be defined as:
FI(0)=0
FI(1)=1
FI(N)=FI(N-1)+FI(N-2) for all N>1

c. Algebraic axioms: Mathematical systems are defined by axioms. The axioms

specify the fundamental properties of a system and provide a basis for deriving
additional properties that are implied by the axioms. These additional properties
are called theorems.
Ex: LIFO property of stack object operations.

NEW Creates a new stack

PUSH Adds a new item to the top of a
stack
TOP Returns a copy of the top item
POP Removes a top item
EMPTY Tests for an empty stack
Operation NEW yields a newly created stack PUSH requires two arguments.

Syntax:
OPERATION DOMAIN RANGE
NEW () STACK
PUSH (STACK, ITEM) STACK
POP (STACK) STACK
TOP (STACK) ITEM
EMPTY (STACK) BOOLEAN

AXIOMS
(1)EMPTY(NEW)= true
(2)EMPTY(PUSH(stack, item))=false
(3)POP(NEW)=error
(4)TOP(NEW)=error
(5)POP(PUSH(stack, item)=stack
(6)TOP(PUSH(stack, item))=item

Page 34
 SOFTWARE ENGINEERING

The axioms can be stated in English:

1. The new stack is empty
2. A stack is not empty immediately pushing an item onto it.
3.Attempting to pop a new stack results in error
4. There is no top item on a new stack
5. Pushing an item onto a stack and immediately popping it off leaves the stack
unchanged.
6. Pushing an item onto a stack and immediately requesting the top item returns
the item just pushed onto the stack.

d. Regular Expressions is used to specify the syntactic structure of symbol

strings. So, regular expressions can thus be viewed as language generators.

Rules for forming Regular Expressions

1. Atoms: The basic symbols in the alphabet of interest form regular
expressions.
2. Alternation: if R1 and R2 are regular expression then (R1|R2) is a regular
expression.
3. Composition: if R1 and R2 are regular expressions then (R1.R2) is a regular
expression.
4. Closure : if R1 is a regular expression, then (R1)* is a regular expression.
5.Completeness: nothing else is a regular expression.

Example
1. Given atoms a and b then a denotes the set {a} and b denotes the set {b}.
2. Given atoms a and b, then (a/b) denotes the set {a,b}
3. Given atoms a, b and c then ((a/b)/c) denotes the set {{a,b},c}
4. Given atoms a and b then (ab) denotes the set {ab} containing one element ab.

5. Given atoms a, b and c then ((ab)c) denotes the set {abc} containing one
element abc.

6. Given atom a, then (a)* denotes the set {e,a,aa,aaa….} e is the empty set.
Ex:

Page 35
 SOFTWARE ENGINEERING

(a(b/c)) {ab,ac}
(a/b)* {e,a,b,aa,bb,ab,ba,aab…..}
((a(b/c)))* {e,ab,ac,abab,acac,abac,acab……}
* Kleene star
+ Kleene plus notations

2. State-oriented notations

a. Design Tables: provides a mechanism for recording complex decision logic.

It is segmented into 4 quadrants.
 Condition stub
 Condition entry
 Action stub
 Action entries.

Basic elements of a decision table

Decision Rules
Rule1 Rule2 Rule3 Rule4
(Condition stub) (Condition entries)
(Action stub) (Action entries)

b. Transition tables
Transition tables are used to specify changes in the state of a system as a
function of driving forces.

Transition Diagram

Page 36
 SOFTWARE ENGINEERING

Transition Table

An augmented Transition Table

 Transition table that is augmented to indicate actions to be performed and

outputs to be generated in the transition to the next state.
 Transition diagrams are alternative representatives for transition tables.
 It is represented as arcs between nodes.

Page 37
 SOFTWARE ENGINEERING

 Arcs are labelled with conditions that cause transitions.

 The transition diagrams and transition tables are representations for finite
state automata.

c. Finite state mechanisms

 Data flow diagrams, regular expressions, transition tables can be
combined to provide a powerful finite mechanism for functional
specification of software systems.

𝐷𝑠 start marker
𝐷11 zero or more 𝐷11 messages
𝐷12 zero or more 𝐷12 messages
𝐷𝐸 end-of-data marker

The system for which the incoming data stream consists of a start marker
𝐷𝑠 , followed by zero or more 𝐷11 messages, followed by zero or more
𝐷12 messages followed by an end-of-data marker 𝐷𝐸 . The purpose is to
split 𝐷11 messages to file 𝐹6 and 𝐷12 messages to file 𝐹7 .

Specification of the “Split” process.

Page 38
 SOFTWARE ENGINEERING

d. Petri Nets

 Petri nets invented by carl petri at the university of Bonn, west germany.
 Petri nets provide a graphical representation technique.
 Petri nets overcome the limitations of finite state mechanisms.
 Petri nets is represented as a bipartite directed graph. Two types of nodes
are called places(tokens) and transitions.
 Petri nets are characterized by an initial marking of places and a firing
rule.
 An enabled transition can fire , when a transition fires, each input place of
that transition loses one token and each output place of that transition
gains one token.
 Petri net defined as a quadruple, consisting of
a set of places P
a set of Transitions T
a set of arcs A
a marking M
C=(P, T, A, M)

Petrinet model of concurrent processes 𝑡1,𝑡2,𝑡3

Page 39
 SOFTWARE ENGINEERING

Completion of 𝑝1 which enables co-begin. Firing of the co-begin removes the

token from 𝑝1 and places in 𝑝2, 𝑝3 ,𝑝4. This enables 𝑡1 ,𝑡2 ,𝑡3. They can fire
simultaneously in any order. When each tasks 𝑡1 ,𝑡2 ,𝑡3 computes, it is placed in
𝑝5 ,𝑝6 ,𝑝7.

A deadlock petri net

Page 40
 SOFTWARE ENGINEERING

Both 𝑡1 and 𝑡2 are waiting for the other to fire and neither can proceed.

 𝑡1 is the producing process, 𝑡2 places a produced item in the buffer

 𝑡3 removes an item from the buffer, 𝑡4 consumes it
 E current number of empty buffer positions
 F indicates the current number of filled buffer positions
 M prevents simultaneous insertion and removal of items from buffer
 Initially M, 𝑃1, 𝑃3 has one token 𝑃2, 𝑃7, 𝑝4, F has zero token E has N
tokens.
 E prevents buffer overflow

Page 41
 SOFTWARE ENGINEERING

 F prevents buffer underflow

 M prevents simultaneous reading and writing of the buffer
 An invariant is a set of places whose total number of tokens remains
constant and which has no invariant subsets.
 ex:{𝑃1,𝑃2} {𝑃3, 𝑝4}{𝑝5, 𝑝7}{𝑝6}
The petri net exhibits mutual exclusion between 𝑡2 and 𝑡3 because both are
marked by 𝑃6 and {𝑃6 } is an invariant, having one token. Thus 𝑡2 and 𝑡3 are
mutually exclusive.

Page 42
 SOFTWARE ENGINEERING

UNIT- III

SOFTWARE DESIGN

Software design – 3 distinct types of activities

a. External Design
b. Architectural Design
c. Detailed Design

The External design and architectural design typically span the period from
software requirements review to preliminary design review. Detailed design
spans the period from preliminary design review to critical design review. The
situations are illustrated as below:

Phases Analysis Design Implementation

Activities Planning External Coding Debugging
requirement Architecture Testing
definition Detailed
SRR PDR CDR

SRR- Software Requirement review

PDR-Preliminary design review
CDR- Critical Design review

Fundamental Concepts of Software Design

1. Abstraction

 Abstraction allows us to organize and channel our thought processes by

postponing structural considerations and detailed algorithmic
considerations, data stores.
Ex: FIFO- Queue(front, rear)
LIFO- Stack( push, pop, Top, new, empty)

3 widely used abstraction mechanisms in software design are

a. functional abstraction(parameterized subroutine)
b. data abstraction.
c. control abstraction.

Page 43
 SOFTWARE ENGINEERING

 The above mechanisms control the complexity of design process.

Abstract
Proceed
Concrete

 Functional abstraction can be generalized to the collection of

subprograms, called ‘groups’ (ex: packages in Ada, Clusters in CLU)
 In a group certain routines have visible property, which allows them to be
used by other groups.
 Hidden routines can be used only within the containing group.
 Abstract data type are representation details of the data items and
implementation details of the functions that manipulate the details of the
functions that manipulate the data items are hidden within the group that
implements the abstract type.
 Control abstraction is used to state a desired effect without stating the
exact mechanism of control.
ex: IF statements and while statements
ex: for all I in S sort files I.

2. Information Hiding
 Information hiding is a fundamental design concept for software.

 When software system is designed using information hiding approach,

each module in the system hides the internal details of its processing
activities and modules communicate only through well-defined interfaces.
 According to parnas, design should begin with a list of difficult design
each module is designed to hide such a decision from other modules.
ex: format of control blocks(queues) character codes ordering of
character sets.

3. Structure
 The use of structure permits decomposition of large system into smaller,
more manageable units with well-defined relationships to other units in
the system.
 The most general form of system structure is a network. It is a directed
graph consisting of nodes and arcs.
Nodes data stores
Arcs information

Page 44
 SOFTWARE ENGINEERING

 A structure inside complex processing node might consist of concurrent

processes executing in parallel and communicating through some
combination of shared variables and synchronous and asynchronous
message passing.

Page 45
 SOFTWARE ENGINEERING

 The entire network might be complex abstraction that provides an

information utility and in turn forms a node in more complex structure of
people and machines.
 The “uses” relationships can be represented by a directed graph, where
the notation A B means “A uses B” or “B is used by A”.
 Hierarchical ordering of abstractions is established by the following rule:
if A and B are distinct entities, and
if A uses B, then B is not permitted to use A or any entity
that makes use of A.
 Hierarchical ordering relation can be represented as an acyclic, directed
graph with a distinguished node that represents a root entity.
 The root uses other entities, but is not used by any entity.
 Hierarchical structure may or may not form a tree structure. The
following figure illustrates directed acyclic graph and a tree structure
respectively.
 The diagram is called structure charts depicts the structure of subroutines
in a system.

Graph structure chart A tree structure chart

Page 46
 SOFTWARE ENGINEERING

Recursive routines should be avoided (A B C A)

 The chart reduces the complexity of iteration among software
components
 The tree structure reduces the complexity of interactions among the
software components.
 In the diagram there are N(N-1)/2 interconnections among N nodes.

Illustrating N(N-1)/2 links among N nodes in a connected graph

 Only N-1 interconnections of N nodes connected in a tree structure. N-1

is the minimum number of interconnections for N nodes

(N-1) links among N nodes in a tree.

 Hierarchical tree structure components and promotes ease of

understanding, implementation, debugging, testing, integration and
modification of a system.

4. Modularity
 A module is a work assignment for an individual programmer.
 Modular systems incorporate collections of abstractions in which each
functional abstraction, data abstraction and control abstraction handles a
local aspect of the problem being solved.

Page 47
 SOFTWARE ENGINEERING

 A modular systems consists of well defined, manageable units with well

defined interfaces among units.

Properties of a modular system include

 Each well-defined subsystem is useful in other applications
 Each abstraction has a single, well defined purpose
 Each function manipulates one major data structure.
 Modularity enhances design clarity, which in turn eases implementation.

5. Concurrency
 Software systems can be categorised as sequential or concurrent.
 In sequential system one portion of the system is active at any given time.

 Concurrency systems have independent processes that can be activated
simultaneously. If multiple processors are available.
Ex: mutual exclusion, deadlock, synchronization of processes.

6. Verification
 Design is the bride between customer requirements and an
implementation that satisfies those requirements.

7. Aesthetics
 When we speak mathematical elegance or structural beauty, we are
speaking of those properties that go beyond mere satisfaction of the
requirement.
ex: supreme court justice, I can’t define it
but I know it when I see it .
Modules and modularization Criteria:
 Architectural design has the goal of producing well structured, modular
software system. The software module named entity has the following
characteristics:
 Modules contain instructions, processing logic and data structures.
 Modules can be separately compiled and stored in a library.
 Modules can be included in a program.
 Module segments can be used by invoking a name and some parameters.
 Modules can use other modules.
 Ex: procedures, subroutines, functions.

Page 48
 SOFTWARE ENGINEERING

1. Coupling and Cohesion

 The fundamental goal of software designs to structure the software
product so that the number of complexity of interconnection between
modules is minimized.
 The strength of coupling between two modules is influenced by the
complexity of the interface, the type of connection, and the type of
communication.
 Obvious relationships results in less complexity.

 Ex: common control blocks, common data blocks, common overlay

regions in memory.

 Loosely coupled= connections established by referring to other module.

 Connections between modules involves, passing of data, passing of

elements(flags, switches, labels and procedure names)
degree of coupling – lowest- data communication
higher- control communication
highest- modify other modules.

Coupling can be ranked as follows:

 a.Content coupling: when one module modifies local data values or
instructions in another module.
 b.Common coupling: are bound together by global data structures
 c.Control coupling: involves passing of control flags between modules
so that one module controls the sequence of processing steps in another
module.
 d.Stamp coupling: similar to common coupling except that global data
items are shared selectively among routines that require the data.
 e.Data coupling: involves the use of parameter lists to pass data items
between routines.

Internal cohesion of a module is measured in terms of the strength of binding of

element within the module.
•Cohesion elements occur on the scale of weakest to strongest as follows.
a. Coincidental cohesion: Module is created from a group of unrelated
instructions that appear several times in other modules.

Page 49
 SOFTWARE ENGINEERING

b. Logical cohesion: implies some relationship among the elements of the

module.
ex: module performs all i/o operations.
c. Temporal cohesion: all elements are executed at one time and no parameter
logic are required to determine which elements to execute.
d. Communication cohesion: refer to same set of input or output data
Ex: ‘print and punch’ the output file is communicational bound.
e. Sequential cohesion: of elements occurs when the output of one element is
the input for the next element.
ex: ‘read next transaction and update master file’
f. Functional Cohesion: is strong type of binding of elements in a module
because all elements are related to the performance of a single function.

Ex: computer square root, obtain random number etc.,

g. Informational cohesion: occurs when the module contains a complex data
structure and several routines to manipulate the data structure.

DESIGN NOTATIONS

1. Data flow diagrams/bubble charts

 Are directed graphs in which the nodes specify processing activities and
the arcs specify data items transmitted between processing nodes.

 Like flow charts DFD can be used at any desired level of abstraction.

 Data flow diagram might represent data flow between individual

statements or blocks of statements in a routine.

 DFD do not indicate decision logic or conditions under which various

processing nodes in the diagram might be activated.

 It can be represented as informal/formal DFD.

Page 50
 SOFTWARE ENGINEERING

INFORMAL DATA FLOW DIAGRAM

FORMAL DFD

Page 51
 SOFTWARE ENGINEERING

2. Structure Charts
used during architectural design to document hierarchical structure,
Parameters and interconnections in a system.

Difference between structure chart and flowchart

 Structure chart has no decision boxes
 Sequential ordering of tasks in a flowchart can be suppressed in a
structure chart

The chart is represented as module by module specification of input output

parameters, as well as input and output parameter attributes .

Page 52
 SOFTWARE ENGINEERING

3. HIPO Diagrams
 HIPO diagrams (hierarchy-process-input-output) were developed at IBM,
as top down software development.
 HIPO diagram contains
a. visual table of contents
b. set of overview diagrams
c. set of detail diagrams
 HIPO consists of a
a. tree structured directory
b. summary of contents of overview diagram
c. Legend of symbol definition

VISUAL TABLE OF CONTENTS FOR A HIPO

Page 53
SOFTWARE ENGINEERING

HIPO table of contents

Page 54
 SOFTWARE ENGINEERING

4. PROCEDURE TEMPLATES
Formal of procedure template:
Procedure Name:
Part of: (subsystem name and number) LEVEL1
Called by:
Purpose:
Designer/date(S):

Parameters:names, modes, attributes, purposes)

Input assertion:(Preconditions)
Output assertion:(post conditions) LEVEL2
Globals(Names, modes, attributes, purposes, shared with)

Local data structures:(names, attributes, purposes)

Exceptions:(Conditions, responses)
Timing constraints: LEVEL3
Other limitations:

Procedure body: (pseudocode, structured english, structured flowchart,

Decision table) LEVEL 4

 In the early stages of architectural design only the information in level1

need to be supplied.
 As design progresses, the information on levels 2,3 and 4 can be included
in successive steps.
 The term side effect means any effect a procedure can exert.
Ex: side effect modifications to global variables, reading/writing a
file, opening or closing a file, calling a procedure that in turn exhibits side
effects.
 During detailed design the processing algorithms and data structures can
be specified using structured flowcharts, pseudocode or structured
English.

5. PSEUDOCODE
 Used both in architectural and detailed design

Page 55
 SOFTWARE ENGINEERING

 The designer of pseudo code, designer describes system characteristics,

using short, concise, English language phrases that are structured by key
words such as if-then-else, while-do and end.

6. STRUCTURED FLOWCHART
 Flowcharts are the traditional means for specifying and documenting
algorithmic details in a software system.
Flowcharts incorporate boxes for actions, diamond shaped boxes for decisions,
directed arcs for specifying interconnections between boxes a variety of
Specifically shaped symbols to denote input, output and datastores.
 Structured flowcharts are preferred where clarity of control flow is
emphasized.

Page 56
SOFTWARE ENGINEERING

Page 57
 SOFTWARE ENGINEERING

Structured flowchart and pseudocode equivalent

Page 58
 SOFTWARE ENGINEERING

7. Structured English
 Used to provide a step-by-step specification for an algorithm.
 Structured english is often used to specify cookbook recipes.
 Preheat oven to 350 degree F.
 Mix eggs, milk and vanilla
 Add flour and baking soda
 Pour into a greased baking dish
 cook until done.

8. Decision Tables
 Used to specify complex decisions logic in a high-level software
specification.
 They are also useful for specifying algorithmic logic during detailed
design.
 Design tables can be specified and translated into source code logic.

DESIGN TECHNIQUES
 The design process involves developing a conceptual view of the system,
establishing system structure, identifying data streams and data stores,
decomposing high level functions into sub functions, establishing
relationships and interconnections among components developing
concrete data representations and specifying algorithmic details.

1. Stepwise Refinement

is a top-down technique for decomposing a system from high level

specifications into more elementary levels.
With defines the following activities:
 a. Decomposing design decisions to elementary levels
 b. Isolating design aspects that is not truly interdependent.
 c. Postponing decisions concerning representation details as long as
possible.
 d. Carefully demonstrating that each successive step is a faithful
expansion of previous steps.

Page 59
 SOFTWARE ENGINEERING

2. Levels of Abstraction
 Describing by Dijkstra as a bottom up design technique, in which it is
designed hierarchically.
 Each level of abstraction is composed of a group of related functions,
some of which are externally visible.
 Each level of abstraction performs a set of services for the functions on
the next higher level of abstraction.

Page 60
 SOFTWARE ENGINEERING

3. Structured Design
 Developed by Constantine as a top down technique for architectural
design of software systems.

 It is systematic conversion of DFD to structured charts

 Design heuristics such as coupling and cohesion are used to guide the
design process

Page 61
 SOFTWARE ENGINEERING

Conversion of DFD to structured chart

 A data dictionary can be used in conjunction with a structure chart to

specify data attributes, relationship among data items and data sharing
among modules in the system.
 The concept of “scope of effect” and “scope of control” can be used to
determine the relative positions of module in a hierarchical framework.

Transaction-driven data flow diagram

Page 62
 SOFTWARE ENGINEERING

Transaction driven systems have dataflow diagram of the form given

above which is converted into a structure chart having input, controller,
dispatcher, update/output subsystems.

Transaction driven structured chart

4. Integrated top-down development

 Integrates design, implementation and testing.
 Design proceeds from the highest level routines
 Primary function of co-ordinating and sequencing the lower-level of
routines.
 The integration, design and implementation is illustrated in the following
example.
 The purpose of main is to co-ordinate and sequence the get, process and
put routines. These 3 routines can communicate only through main.
Similarly sub1 and sub2 can communicate only through process.

Page 63
 SOFTWARE ENGINEERING

5. Jackson Structured Programming

 Developed by Michael jackson as a systematic technique of mapping the
structure of a problem into a program structure to solve the problem.

Mapping 3 steps:
1. The problem is modelled by specifying the input and output data structures
using tree structured diagrams.
2. The input and output model is converted into a structural model of the
program.
3. The structural model of the program is expanded into a detailed design model
that contains the operations needed to solve the problem.

 Input and output structures are specified using a graphical notation to

specify data hierarchy, sequences of data, repetition of data items and
alternate data items.

Page 64
 SOFTWARE ENGINEERING

 Convert the above model into structural model

 Third step structure model to detailed model involves 3 steps:
1.A list of operations required to perform the processing steps is developed
2. The operations are associated with the program structure
3. Program structure and operations are expressed in a notation called schematic
logic which is stylized pseudo code.

Input and output structure for an inventory problem

Page 65
 SOFTWARE ENGINEERING

Correspondence between input and output structure for an inventory problem

Program structure for an inventory problem

Page 66
 SOFTWARE ENGINEERING

Detailed Design involves developing a

 List of operations needed in the program
 Associating the operations with program
 Structure and translating the annotated structure diagram into schematic
logic(Psudocode)

Association of operations with program structure

Page 67
 SOFTWARE ENGINEERING

WALKTHROUGH
 Walkthrough is a method of conducting informal group/individual
review. In a walkthrough, author describes and explain work product in a
informal meeting to his peers or supervisor to get feedback. Here, validity
of the proposed solution for work product is checked.
 It is cheaper to make changes when design is on the paper rather than at
time of conversion. Walkthrough is a static method of quality assurance.
Walkthrough are informal meetings but with purpose. 
INSPECTION
 An inspection is defined as formal, rigorous, in depth group review
designed to identify problems as close to their point of origin as possible.
Inspections improve reliability, availability, and maintainability of
software product.
 Anything readable that is produced during the software development can
be inspected. Inspections can be combined with structured, systematic
testing to provide a powerful tool for creating defect-free programs.
 Inspection activity follows a specified process and participants play well-
defined roles. An inspection team consists of three to eight members who
play roles of moderator, author, reader, recorder and inspector.

SOFTWARE DESIGN
 Software design is an iterative process through which requirements are
translated into a “blueprint” for constructing the software. The design is
represented at a high level of abstraction. As design iterations occur,
subsequent refinement leads to design representation at much lower
levels of abstraction.
 A set of principles for software design:
 The design process should not suffer from “tunnel vision”.
 The design should be traceable to the analysis model.
 The design should not reinvent the wheel.
 The design should “minimize the intellectual distance” between the
software and the problem in the real world.
 The design should exhibit uniformity and integration.
 The design should be structured to accommodate change.
 The design should be structured to degrade gently.
 Design is not coding.
 The design should be assessed for quality.

Page 68
 SOFTWARE ENGINEERING

UNIT-IV

STRUCTURED CODING TECHNIQUES

 The goal of structured coding is to sequencing control flow through a

computer program so that the execution sequence follows the sequence in
which the code is written. Linear flow of control can be achieved by restricting
the set of allowed program constructs to single entry, single exit formats;
however, strict loyalty to nested, single entry, single exit constructs leads to
questions concerning efficiency, questions about “reasonable” violations of
single entry, single exit, and questions about the proper role of the go to
statements in structured coding.

Programming Language Characteristics

 Programming languages are vehicle for communication between humans

and computers. The coding process communication through a programming
language is a human activity.
 The Psychological characteristics of a language have an important impact
on the quality of communication. The coding process may also be viewed as
one step in the S/W development project.
 The technical characteristics of a language can influence the quality of
design. The technical characteristics can affect both human and S/W
engineering concerns.

A Psychological View

A number of psychological characteristics occur as a result of programming

language design. Although these characteristics are not measurable in any way,
their manifestations in all the programming languages are recognized. The
different characteristics are,

• Uniformity – The indicates the degree to which a language use consistent

notation applies arbitrary restrictions and supports syntactic or semantic
exceptions to the rule.

• Ambiguity – This is a programming language that is perceived by the

programmer. A compiler will always interpret a statement in one way but
the human reader may interpret the statement differently.

• Compactness – A programming language is an indication of the amount

Page 69
 SOFTWARE ENGINEERING

of code-oriented information that must be recalled from the human

memory. The characteristics of human memory have a strong impact on
the manner in which a language is used. Human memory and
recognition may be divided into synthetic and sequential domains.
Synesthetic memory allows remembering and recognizing the things as a
whole. Sequential memory provides a means for recalling the next
element in a sequence. Each of these; memory characteristics affect
programming language characteristics that are called Locality and
linearity.

o Locality- Is the synthetic characteristic of a programming language.

Locality is enhanced when statements may be combines into
blocks when the structured constructs may be implemented
directly, and when design and resultant code are modular and
cohesive.

o Linearity – Is a psychological characteristic that is closely

associated with the concept of maintenance of functional domain.
Extensive branching violates the linearity of processing.

• Tradition- A software engineer with a background in FORTRAN would

have little difficulty learning PASCAL or C. The latter languages have a
tradition established by the former. The constructs are similar, the form
is compatible and a sense of programming language format is maintained.
However if the same S/W engineer is required to earn APL, LISP or Small
talk, tradition would be broken and time on the learning curve would be
longer.

The Psychological characteristics of a programming language have an important

bearing on our ability to learn apply and maintain them.

A Syntactic / Semantic Model

When a programmer applies S/W engineering methods that are

programming language-independent, semantic knowledge is used. Syntactic
knowledge on other hand is language dependent, concentrating on the
characteristics of a specific language.
The semantic knowledge is the more difficult to acquire and also more
intellectually demanding to apply. All S/W engineering steps that precede
coding make heavy use of semantic knowledge. The coding step applies
syntactic knowledge that is arbitrary and instructional. When a new

Page 70
 SOFTWARE ENGINEERING

programming language is learn, the new syntactic information is added to

memory. Potential confusion may occur when the syntax of a new
programming language is similar but not equivalent to the syntax of another
language.

An Engineering View

A S/W engineering view of programming language characteristics focuses on

the needs of specific S/W development project. The characteristics are,

• Ease of design to code translation.

• Compiler efficiency.
• Source code portability.
• Availability of development tools.
• Availability of libraries
• Company policy
• External requirements
• Maintainability.

The ease of design to code translation provides an indication of how closely

a programming language reflects a design representation. A language that
directly implements the structured constructs, sophisticated data structures,
specialized I/O, bit manipulation capabilities and object oriented constructs will
make translation from design to source code much easier.

The quality of the compiler is important for the actual implementation

phase. A good compiler should not only generate efficient code, but also
provide support for debugging (e.g. with clear error messages and run-time
checks).

Although fast advances in processor speed and memory density have begun to
satisfy the need for super efficient code may applications still require fast and
low memory requirement programs. Particularly in the area of microcomputers,
many compilers have been integrated in development systems. Here the
userfriendliness of such systems must also be considered.

The source code portability can be as follows:

• The source code may be transported from processor to processor and

compiler to compiler with little or no modification.

Page 71
 SOFTWARE ENGINEERING

• The source code remains unchanged even when its environment changes.
• The source code may be integrated into different software packages with
little or not modification required because of programming language
characteristics.

The availability of development tools can shorten the time required to

generate source code and can improve the quality of code. Many programming
languages may e acquired with a set of tools that include debugging compilers,
source code formatting aids, built-in editing facilities, tools for source code
control, extensive subprogram libraries, browsers, cross-compilers for
microprocessor development, microprocessor capabilities and others.

With modular programming languages, the availability of libraries for

various application domains represents a significant selection criterion. For
example, for practically all FORTRAN compilers, libraries are available with
numerous mathematical functions, and Smalltalk class libraries contain a
multitude of general classes for constructing interactive programs. The
availability of libraries can also be used in C or Modular-2 if the compiler
supports linking routines from different languages. On the other hand, there
are libraries that are available only in compiled form and usable only in
connection with a certain compiler.

Often a particular company policy influences the choice of a programming

language. Frequently the language decision is made not by the implementers,
but by managers that want to use only a single language company-wide for
reasons of uniformity. Such a decision was made by the U.S. Department of
Defense, which mandates the use of ADA for all programming in the military
sector in the U.S (and thus also in most other NATO countries). Such global
decisions have also been made in the area of telecommunications, where many
programmers at distributed locations work over decades on the same product.
Even in-house situations, such as the education of the employees or a
module library built up over years, can force the choice of a certain language. A
company might resist switching to a more modem programming language to
avoid training costs, the purchase of new tools, and the re-implementation of
existing software.
Sometimes external requirements force the use of a given programming
language. Contracts for the European Union increasingly prescribe ADA, and
the field of automation tends to require programs in FORTRAN or C. Such
requirements arise when the client’s interests extend beyond the finished
product in compiled form and the client plans to do maintenance work and
further development in an in-house software department. Then the education

Page 72
 SOFTWARE ENGINEERING

level of the client’s programming team determines the implementation

language.
Maintainability of source code is important for all nontrivial software
development efforts. Maintenance cannot be accomplished until S/W is
understood. The earlier elements of the S/W configuration provide a
foundation for understanding, but the source code must be real and modified
according to the changes in design. The self-documenting characteristics of a
language have a strong influence on maintainability.

CODING STYLE

The readability of a program depends on the programming language used

and on the programming style of the implementer. Writing readable programs is
a creative process. Once the source code has been generated the function of a
module should be apparent without reference to a design specification. The
programming style of the implementer influences the readability of a program
much more than the programming language used. A stylistically well-written
FORTRAN or COBOL program can be more readable than a poorly written
Modula-2 or Smalltlak program. Coding style encompasses a coding philosophy
that stresses simplicity and clarity.
The elements of style include the following:

i. Structuredness
ii. Expressiveness
iii. Data declaration
iv. Statement construction
v. Input/Output
vi. Outward form
vii. Efficiency
This refers to both the design and the implementation.
Although efficiency is an important quality attribute, we do not deal with
questions of efficiency here. Only when we understood a problem and its
solution correctly does it make sense to examine efficiency.

Structuredness
_ Decomposing a software system with the goal of mastering its complexity
through abstraction and striving for comprehensibility (Structuring in the
large.)

_ Selecting appropriate program components in the algorithmic formulation of

Page 73
 SOFTWARE ENGINEERING

subsolutions (Structuring in the small.)

a. Structuring in the large

_ Classes and methods for object-oriented decomposition
_ Modules and procedures assigned to the modules.
_ During implementation the components defined in the design must be
realized in such a way that they are executable on a computer. The
medium for this translation process is the programming language.
_ For the implementation of a software system, it is important that the
decomposition defined in the design be expressible in the programming
language; i.e. that all components can be represented in the chosen
language.
b. Structuring in the small
_ The understanding and testing of algorithms require that the algorithms
be easy to read.
_ Many complexity problems ensure from the freedom taken in the use of
GOTO statements, i.e., from the design of unlimited control flow
structures.
_ The fundamental ideal behind structured programming is to use only
control flow structures with one input and one output in the formulation
of algorithms. This leads to a correspondence between the static written
form of an algorithm and its dynamic behavior. What the source code
lists sequentially tends to be executed chronologically. This makes
algorithms comprehensible and easier to verify, modify or extend.
_ Every algorithm can be represented by a combination of the control
elements sequence, branch and loop (all of which have one input and one
output) ([Böhm 1996]).
_ D-diagrams (named after Dijkstra): Diagrams for algorithm consisting of
only elements sequence, branch and loop.
Note: If we describe algorithms by a combination of these elements, no
GOTO statement is necessary. However, programming without GOTO
statements alone cannot guarantee structuredness. Choosing
inappropriate program components produces poorly structured programs
even if they contain no GOTO statements.

Expressive power (Code Documentation)

_ The implementation of software systems encompasses the naming of objects

and the description of actions that manipulate these objects.
_ The choice of names becomes particularly important in writing an algorithm.
Recommendation:

Page 74
 SOFTWARE ENGINEERING

• Choose expressive names, even at the price of long identifiers. The

writing effort pays off each time the program must be read, particular
when it is to be corrected and extended long after its implementation. For
local identifiers (where their declaration and use adjoin) shorted names
suffice.
• If you use abbreviations, then use only ones that the reader of the
program can understand without any explanation. Use abbreviations
only in such a way as to be consistent with the context.
• Within software system assign names in only one language (e.g. do not
mix English and Vietnamese).
• Use upper and lower case to distinguish different kinds of identifiers (e.g.,
upper case first letter for data types, classes and modules; lower case for
variables) and to make long names more readable
(e.g. CheckInputValue).
• Use nouns for values, verbs for activities, and adjectives for conditions to
make the meaning of identifiers clear (e.g., width, ReadKey and valid,
respectively).
• Establish your own rules and follow them consistently.
_ Good programming style also finds expression in the use of comments: they
contribute to the readability of a program and are thus important program
components. Correct commenting of programs is not easy and requires
experience, creativity and the ability to express the message concisely and
precisely.
The rules for writing comments:
• Every system component (every module and every class) should begin
with a detailed comment that gives the reader information about several
questions regarding the system component:
- What does the component do?
- How (in what context) is the component used?
- Which specialized methods, etc. are use?
- Who is the author?
- When was the component written?
- Which modifications has have been make?
Example:
/* FUZZY SET CLASS: FSET
FSET.CPP 2.0, 5 Sept. 2007
92
Lists operations on fuzzy sets
Written by Suresh Babu
*/
• Every procedure and method should be provided with a comment that

Page 75
 SOFTWARE ENGINEERING

describes its task (and possibly how it works). This applies particularly
for the interface specifications.
• Explain the meaning of variables with a comment.
• Program components that are responsible for distinct subtasks should be
labeled with comments.
• Statements that are difficult to understand (e.g. in tricky procedures or
program components that exploit features of a specific computer) should
be described in comments so that the reader can easily understand them.
• A software system should contain comments that are as few and as
concise as possible, but as many adequately detailed comments as
necessary.
• Ensure that program modifications not only affect declarations and
statements but also are reflected in updated comments. Incorrect
comments are worse than none at all.
Note: These rules have deliberately been kept general because there are no rules
that apply uniformly to all software systems and every application domain.
Commenting software systems is an art, just like the design and implementation
of software systems.

Data declaration

The style of the data description is established when code is generated. A

number of relatively simple guidelines can be established to make data more
understandable and maintenance simpler. The order of data declarations
should be standardized even if the programming language has no mandatory
requirements. Ordering makes attributes easier to find, expediting testing,
debugging and maintenance. When multiple variable names are declared with
a single statement, an alphabetical ordering of names is used. Similarly,
labeled global data should be ordered alphabetically. If complex data
structures are used in design, the commenting should be used to explain
peculiarities that are present in a programming language implementation.

Statement Construction

The construction of software logical flow is established during design. The

construction of individual statements, is apart of the coding step. Statement
construction should abide by one overriding rule. Each statement should be
simple and direct and code should not be complicated to effect efficiency. Many
programming languages allow multiple statements per line. The spaces saving
aspects of this feature are hardly justified by poor readability that results.
Individual source coder statements can be simplified by,

Page 76
 SOFTWARE ENGINEERING

• Avoiding the use of complicated conditional tests. 93

• Eliminating tests on negative conditions.
• Avoiding heavy nesting of loops or conditions
• Use of parenthesis to clarify logical or arithmetic expressions.

Input / Output

The style of input and output is established during S/W requirements

analysis and design and not coding Input and output style will vary with the
degree of human interaction. For batch oriented I/O, logical input organization,
meaningful Input/Output error checking, good I/O error recovery and rational
output report formats are desirable characteristics. For Interactive I/O, a
simple guided input scheme, extensive error checking and recovery, human
engineered output, and consistency of I/O format are the primary concerns.

Outward form
_ Beyond name selection and commenting, the readability of software systems
also depends on its outward form.
Recommended rules for the outward form of programs:
• For every program component, the declarations (of data types, constants,
variables, etc.) should be distinctly separated form the statement section.
• The declaration sections should have a uniform structure when possible,
e.g. using the following sequence: constant, data types, classes and
modules, methods and procedures.
• The interface description (parameter lists for method and procedures)
should separate input, output and input/output parameters.
• Keep comments and source code distinctly separate.
• The program structure should be emphasized with indentation.

Efficiency

In well engineered systems, there is a natural tendency to use critical

resources efficiently. Processor cycles and memory locations are viewed as
critical resources. Three area of Efficiency should be taken care when a
programming language is developed. They are,
a) Code Efficiency
b) Memory Efficiency
c) Input /Output Efficiency
a. Code Efficiency: The efficiency of source code is directly connected to the
efficiency of algorithms defined during detailed design. However, the coding
style can affect the execution speed and memory requirement. The following

Page 77
 SOFTWARE ENGINEERING

guidelines can be applier when detail design is translated into code.

• Simplify arithmetic and logical expressions before committing to
code.

• Carefully evaluated the nested loops.

• Avoid use of multi-dimensional arrays.
• Avoid the use of pointers and complete lists.
• Don’t mix data types.
b. Memory Efficiency – Memory restrictions in the large machines like
mainframes and workstation are a thing of the past. Low-cost memory provides
a large physical address space and virtual memory management provides
application software with an enormous logical address space. Memory
efficiency for such environments cannot be elated to minimum memory used.
Memory efficiency must take into account the paging characteristics of an
operating system. Maintenance of functional domain through the structured
constructs is an excellent method for reducing paging and thereby increases
efficiency.
c. Input/Output Efficiency – Two classes of I/O should be considered when
efficiency is discussed. They are,
• I/O directed to human (user),
• I/O directed to another device.
Input supplied by a user and output produced for a user is efficient when the
information can be supplier or understood with an economy of intellectual
effort.
Efficiency of I/O to other hardware is an extremely complicated topic and the
following guidelines improve I/O efficiency.
• The number of I/O requests should be minimized.
• All I/O should be buffered to reduce communication overhead
• I/O to secondary memory devices should be blocked
• I/O to terminals and printers should recognize features of the device that
could improve quality or speed.

STANDARDS AND GUIDELINES

Coding standards are specifications for a preferred coding style. Give a

choice of ways to achieve an effect, a preferred way is specified. Coding
standards are often viewed by programmers as mechanisms to constrain and
devalue the programmer’s creative problem solving skills. It is desirable that all
programmers on a software project adopt similar coding styles so that code of
uniform quality is produced. This does not mean that all programmers must
think alike, or that they must slavishly implement all algorithms in exactly the

Page 78
 SOFTWARE ENGINEERING

same manner. Indeed, the individual style of each programmer on a project is

identical even when right adherence to standards of programming style is
observed.
A programming standard might specify items such as
1. Goto Statements will not be used.95
2. The nesting depth of program constructs will not exceed five levels.
3. Subroutine length will not exceed 30 lines.
A Guideline rephrases these specifications in the following manner:
1. The use of goto statements should be avoided in normal circumstances.
2. The nesting depth of program constructs should be five or less in normal
circumstances.
3. The number of executable statements in a subprogram should not
exceed 30 in normal circumstances.
4. Departure from normal circumstances requires approval by the project
leader.

Software Quality Assurance (SQA) is simply a way to assure quality in the

software. It is the set of activities which ensure processes, procedures as well as
standards suitable for the project and implemented correctly.
Software Quality Assurance is a process which works parallel to development
of a software. It focuses on improving the process of development of software
so that problems can be prevented before they become a major issue. Software
Quality Assurance is a kind of an Umbrella activity that is applied throughout
the software process.
Software Quality Assurance has:
•A quality management approach
•Formal technical reviews
•Multi testing strategy
•Effective software engineering technology
•Measurement and reporting mechanism

Major Software Quality Assurance Activities:

• SQA Management Plan: Make a plan how you will carry out the sqa through
out the project. Think which set of software engineering activities are the best
for project.check level of sqa team skills.
• Set The Check Points: SQA team should set checkpoints. Evaluate the
performance of the project on the basis of collected data on different check
points.

Page 79
 SOFTWARE ENGINEERING

• Multi testing Strategy: Do not depend on single testing approach. When you
have lot of testing approaches available use them.
• Measure Change Impact: The changes for making the correction of an error
sometimes re introduces more errors keep the measure of impact of change on
project. Reset the new change to change check the compatibility of this fix with
whole project.

Manage Good Relations: In the working environment managing the good

relation with other teams involved in the project development is mandatory. Bad
relation of SQA team with programmers team will impact directly and badly on
project. Don’t play politics.
Benefits of Software Quality Assurance (SQA):
 SQA produce high quality software.
 High quality application saves time and cost.
 SQA is beneficial for better reliability.
 SQA is beneficial in the condition of no maintenance for long time.
 High quality commercial software increase market share of company.
 Improving the process of creating software.
 Improves the quality of the software.

Static Analysis
 Static analysis involves a set of methods used to analyze software source
code or object code determine how the software functions and establish
criteria to check its correctness. Static analysis studies the source code
without executing it and reveals a wide variety of information such as the
structure of the model used, data and control flow, syntax accuracy, and
more.
There are several types of static analysis methods-
Control Analysis :-
 This software focuses on examining the controls used in calling structure,
control flow analysis and state transition analysis. The calling structure is
related to the model by identifying the calling and call structure.

Page 80
 SOFTWARE ENGINEERING

 The calling structure can be a process, subroutine, function, or method.

Control flow analysis checks the sequence of control transfers.
Furthermore, it inefficient constructions in the model. A graph of the
model is created in which the conditional branches and model junctions
are represented by nodes.

Data Analysis :-
 Ensures proper operation is applied to data objects such as data structures
and linked lists. In addition, this method also ensures that the defined data
is used properly. Data analysis involves two methods, namely, data
dependency and data-flow analysis. Data dependency is necessary to
assess the accuracy of synchronization across multiple processors. Data
flow analysis checks the definition and context of variables.
Fault/Failure Analysis :-
 It analyzes faults (incorrectly component) and failure (incorrect behavior
of model component) in the model. This method uses the input-output
transformation description to identify the conditions that are cause for the
failure. To determine the failures in certain conditions the model design
specification is checked.
Interface Analysis :-
 This software verifies and verifies interactive and distribution simulations
to check the code. There are two basic techniques for interface analysis
and user interface analysis examines sub model interfaces and determines
the accuracy of interface structure. User interface analysis examines the
user interface model and for the precautionary steps taken to prevent
errors during the user’s interaction with the model. This method also
focuses on how accurately the interface is integrated into the overall
model and simulation.

Symbolic Execution
Symbolic execution is a software testing technique that is useful to aid the
generation of test data and in proving the program quality.

Steps to use Symbolic Execution:

 The execution requires a selection of paths that are exercised by a set of

data values. A program, which is executed using actual data, results in the
output of a series of values.

Page 81
 SOFTWARE ENGINEERING

 In symbolic execution, the data is replaced by symbolic values with set of

expressions, one expression per output variable.
 The common approach for symbolic execution is to perform an analysis
of the program, resulting in the creation of a flow graph.
 The flow graph identifies the decision points and the assignments
associated with each flow. By traversing the flow graph from an entry
point, a list of assignment statements and branch predicates is produced.

Issues with Symbolic Execution:

 Symbolic execution cannot proceed if the number of iterations in the loop
is known.
 The second issue is the invocation of any out-of-line code or module
calls.
 Symbolic execution cannot be used with arrays.
 The symbolic execution cannot identify of infeasible paths.

Symbolic Execution Application:

 Path domain checking
 Test Data generation
 Partition analysis
 Symbolic debugging

UNIT TESTING AND DEBUGGING

What is Unit Testing?

 Unit testing, a testing technique using which individual modules are
tested to determine if there are any issues by the developer himself. It is
concerned with functional correctness of the standalone modules.
 The main aim is to isolate each unit of the system to identify, analyze and
fix the defects.

Unit Testing - Advantages:

Page 82
 SOFTWARE ENGINEERING

 Reduces Defects in the newly developed features or reduces bugs when

changing the existing functionality.
 Reduces Cost of Testing as defects are captured in very early phase.
 Improves design and allows better refactoring of code.
 Unit Tests, when integrated with build gives the quality of the build as
well.

Unit Testing LifeCyle:

Unit Testing Techniques:

Black Box Testing - Using which the user interface, input and output are tested.

Page 83
 SOFTWARE ENGINEERING

White Box Testing - used to test each one of those functions behaviour is
tested.
Gray Box Testing - Used to execute tests, risks and assessment methods.

Debugging
 Debugging is the process of fixing a bug in the software. In other words,
it refers to identifying, analyzing and removing errors. This activity
begins after the software fails to execute properly and concludes by
solving the problem and successfully testing the software. It is considered
to be an extremely complex and tedious task because errors need to be
resolved at all stages of debugging.

Debugging Process: Steps involved in debugging are:

 Problem identification and report preparation.
 Assigning the report to software engineer to the defect to verify that it is
genuine.
 Defect Analysis using modelling, documentations, finding and testing
candidate flaws, etc.
 Defect Resolution by making required changes to the system.
 Validation of corrections.

Debugging Strategies:
 Study the system for the larger duration in order to understand the
system. It helps debugger to construct different representations of systems
to be debugging depends on the need. Study of the system is also done
actively to find recent changes made to the software.
 Backwards analysis of the problem which involves tracing the program
backward from the location of failure message in order to identify the
region of faulty code. A detailed study of the region is conducting to find
the cause of defects.
 Forward analysis of the program involves tracing the program forwards
using breakpoints or print statements at different points in the program
and studying the results. The region where the wrong outputs are obtained
is the region that needs to be focused to find the defect.
 Using the past experience of the software debug the software with similar
problems in nature. The success of this approach depends on the expertise
of the debugger.

Page 84
 SOFTWARE ENGINEERING

SYSTEM TESTING
 System Testing (ST) is a black box testing technique performed to
evaluate the complete system the system's compliance against specified
requirements. In System testing, the functionalities of the system are
tested from an end-to-end perspective. System Testing is usually carried
out by a team that is independent of the development team in order to
measure the quality of the system unbiased. It includes both functional
and Non-Functional testing.

FORMAL VERIFICATION

Page 85
 SOFTWARE ENGINEERING

Advantages of Formal Verification

Page 86
 SOFTWARE ENGINEERING

SOFTWARE MAINTENANCE
 Software maintenance is widely accepted part of SDLC now a days. It
stands for all the modifications and updating done after the delivery of
software product. There are number of reasons, why modifications are
required, some of them are briefly mentioned below:
 Market Conditions - Policies, which changes over the time, such as
taxation and newly introduced constraints like, how to maintain
bookkeeping, may trigger need for modification.
 Client Requirements - Over the time, customer may ask for new features
or functions in the software.
 Host Modifications - If any of the hardware and/or platform (such as
operating system) of the target host changes, software changes are needed
to keep adaptability.
 Organization Changes - If there is any business level change at client
end, such as reduction of organization strength, acquiring another
company, organization venturing into new business, need to modify in the
original software may arise.

Types of maintenance
Following are some types of maintenance based on their characteristics:

Page 87
 SOFTWARE ENGINEERING

 Corrective Maintenance - This includes modifications and updations

done in order to correct or fix problems, which are either discovered by
user or concluded by user error reports.
 Adaptive Maintenance - This includes modifications and updations
applied to keep the software product up-to date and tuned to the ever
changing world of technology and business environment.
 Perfective Maintenance - This includes modifications and updates done
in order to keep the software usable over long period of time. It includes
new features, new user requirements for refining the software and
improve its reliability and performance.
 Preventive Maintenance - This includes modifications and updations to
prevent future problems of the software. It aims to attend problems,
which are not significant at this moment but may cause serious issues in
future.

Real-world factors affecting Maintenance Cost

 The standard age of any software is considered up to 10 to 15 years.
 Older software’s, which were meant to work on slow machines with less
memory and storage capacity cannot keep themselves challenging against
newly coming enhanced software’s on modern hardware.
 As technology advances, it becomes costly to maintain old software.
 Most maintenance engineers are newbie and use trial and error method to
rectify problem.
 Often, changes made can easily hurt the original structure of the software,
making it hard for any subsequent changes.
 Changes are often left undocumented which may cause more conflicts in
future.

What is Software Configuration Management?

Software Configuration Management(SCM) is a process to systematically

manage, organize, and control the changes in the documents, codes, and other
entities during the Software Development Life Cycle. The primary goal is to
increase productivity with minimal mistakes. SCM is part of cross-disciplinary
field of configuration management and it can accurately determine who made
which revision.

Page 88
 SOFTWARE ENGINEERING

Tasks in SCM process

 Configuration Identification
 Baselines
 Change Control
 Configuration Status Accounting
 Configuration Audits and Reviews

Configuration Identification:
 Configuration identification is a method of determining the scope of the
software system. With the help of this step, you can manage or control
something even if you don't know what it is. It is a description that
contains the CSCI type (Computer Software Configuration Item), a
project identifier and version information.

Baseline:
 A baseline is a formally accepted version of a software configuration
item. It is designated and fixed at a specific time while conducting the
SCM process. It can only be changed through formal change control
procedures.

Activities during this process:

 Facilitate construction of various versions of an application
 Defining and determining mechanisms for managing various versions of
these work products
 The functional baseline corresponds to the reviewed system requirements
 Widely used baselines include functional, developmental, and product
baselines
 In simple words, baseline means ready for release.

Change Control:
 Change control is a procedural method which ensures quality and
consistency when changes are made in the configuration object. In this
step, the change request is submitted to software configuration manager.
Activities during this process:

Page 89
 SOFTWARE ENGINEERING

 Control ad-hoc change to build stable software development

environment. Changes are committed to the repository
 The request will be checked based on the technical merit, possible side
effects and overall impact on other configuration objects.
 It manages changes and making configuration items available during the
software lifecycle

Configuration Status Accounting:

 Configuration status accounting tracks each release during the SCM
process. This stage involves tracking what each version has and the
changes that lead to this version.

Activities during this process:

 Keeps a record of all the changes made to the previous baseline to reach a
new baseline
 Identify all items to define the software configuration
 Monitor status of change requests
 Complete listing of all changes since the last baseline
 Allows tracking of progress to next baseline
 Allows to check previous releases/versions to be extracted for testing

Configuration Audits and Reviews:

 Software Configuration audits verify that all the software product
satisfies the baseline needs. It ensures that what is built is what is
delivered.
Activities during this process:
 Configuration auditing is conducted by auditors by checking that defined
processes are being followed and ensuring that the SCM goals are
satisfied.
 To verify compliance with configuration control standards. auditing and
reporting the changes made .
 SCM audits also ensure that traceability is maintained during the process.
 Ensures that changes made to a baseline comply with the configuration
status reports.
 Validation of completeness and consistency.

Page 90
SOFTWARE ENGINEERING

Page 91