Unit-I

INTRODUCTION TO SOFTWARE ENGINEERING

Def: Software engineering is the technological & managerial discipline concerned with
systematic production and maintenance of software products that are developed and modified
on time and within cost estimates.
• Software engineering is concerned with
– applying computer science,
– management skills,
– quality concerns,
– business needs and
– ethical considerations
• To describing and building software-intensive systems
– that satisfy human needs and wants
– that are built in a timely and economical manner
– that are safe, secure, and reliable
– that improve human life
– that create jobs and wealth
– Software engineering is concerned with applying science, technology, and management
skill to develop products and systems for use by society within the constraints of:
– Time : schedule
– Resources : human, corporate assets
– Technology : platform and domain
– Quality : safety, security, reliability,
– Business : competition, profit, stability, growth
– Ethics : serving society

Goals of Software Engineering

• The primary goals of software development (and modification) are to develop software-
intensive systems that:
– satisfy technical requirements, user needs, and customer expectations
– are developed on time and within budget
– are easy to modify and maintain
– support the business goals of our organization
– instill pride in the developers

Software Engineering Roles

• There are many roles to be played in software engineering:

– User – programmer
– customer – tester
– project manager – configuration manager
– system engineer – quality assurer
– software architect – documenter
– software designer – trainer
and so forth

1 Class Notes Prepared By PDS

 • We must distinguish the roles from the people who play those roles:
– each role requires certain skills
– many people may be required to play one role
– one person may play many roles
• at the same time
• at different times
Some Definition
• Software Engineering differs from Computer programming
– Here the Engineering methology are used to
specify,Design,implement,validate,maintain software products within the time
and budget.
– On small project(1 or 2 programmers, duration is 1 or 2 months)
primarily technical.
– On projects involving more programmers and longer durations,
management control is required to coordinate the technical activities
 Terms:
 Programmer:
• An individual who is concerned with details of implementing, packaging and modifying
algorithms, data structures, returning programming languages.
 Software Engineers:
• Concern with the issues of

1. Analysis 4. Documentations
2. Design 5. Software maintenance
3. Verification &Testing 6. Project Management

 Computer Software:
• It includes the Source code and all the associated documents and documentation that
constitute the software product.
Components of Software products :
 Documentation:

1. Requirements Documents 6. Quality assurance procedure

2. Design specification 7. Software problem reports
3. Source code 8. maintenance procedures
4. Test Plans 9. Users manual
5. Principles of Operation 10. Installation Instruction

11. Training Aids.

o Internal Documentation - it describes the characteristics of the code.

2 Class Notes Prepared By PDS

 o External Documentation - it explains the characteristic of the documentation
associated with code.
 Developer:
- Developer or Software Engineer are used interchangeable.
 Customer:
- An individual or organization.
 Software Reliability:
- The ability of a program to perform a required function and their stated conditions for
a stated period of time.
Size Factors
 Total effort devoted to software:
• In 1960 the ratio was approximately 80% Hardware cost and 20% Software cost.
• In 1980 the ratio was reversed. 80 % for software cost and 20% for Hardware cost.
• The reason is the transistors, Intetpreter circuits have resulted in dramatic decreases in
Hardware cost.

 Distribution of Effort:
• Life cycle of Software

1. Analyze & Design 4. Adapt

2. Implement 5. Enhance
3. Test 6. Fix

• The life span of software products is one to 3 years for development 5to 15 years for
maintenance.
Software maintenance involves 3 activities.
a) Enhancing the capability of the product.
b) Adapting the products to new processing environments
c) Correcting bugs.

3 Class Notes Prepared By PDS

  Distribution of Maintenance:
Enhancement—60%
Adaptation—20%
Correction ---20%
Distribution of effort for development phase
1. Analysis & Design—40%
2. Implementation,Debugging,unit testing –20%
3. Integration & Acceptance testing—40%
• From observations, Software maintenance activities consumed more resources than
software development activities.
• A large percentage of total effort is devoted to software enhancement.
• Testing requires half the effort during software development .
• Activities of system testing, enhancement, adaptation consumed ¾ th of total life cycle
effort
 Project Size Categories:
• Project size is a major factor that determines the level of management control and the
types of tools and techniques required on a software project.

 Trivial Project:
No.of programmers : 1
Duration : for a few days, few weeks
Product Size : 500 source line
Packaged in : 10 to 20 subroutines
• These Programs are often personal software Developed exclusively for the use of the
programmer.
• Small amount of formal analysis, elaborate design documentation, extensive test
planning or supporting documents are needed.
 Small Project:
No.of programmers : 1
Duration : 1 to 6 months
Product Size : 1000 to 2000 source lines

4 Class Notes Prepared By PDS

 Packaged in 25 to 50 subroutines
• Example, Scientific applications written by engineers to solve numerical problems.
• Students Projects written in compiler and Operating System.
• Standardized techniques and notations, standardized documents and systematic project
reviews should be used in small projects.
 Medium Size Projects:
No.of Programmers : 2 to 5
Duration : 1 to 2 years
Product Size : 10,000 to 15,000 source lines
Packaged in 250 to 1000 routines.
Examples
• Medium size projects includes assesmblers, Compilers, Small management information
system, inventory system and Process control applications.
• To develop such programs, interaction among programmers and Customers is required.
• A certain degree of formality is required in planning, documents and project reviews.
• Most application programs, System programs are developed in 2 years or less by 5.
 Larger Size Projects:
No.of Programmers : 5 to 20
Duration : 2 to 3years
Product Size : 50,000 to 1 lakhs source lines.
Packaged in several sub systems.
Examples
Compilers, Small time sharing systems, database packages, graphic packages and real
time control systems.
• Large programs has significant interactions with other programs and sub systems.
• Communication among programmers,managers,customers are needed.
• The larger projects requires more than 1 programming team.
• Example, three teams of 5 persons each.
 Very Large Projects:
No.of Programmers : 100 to 1000
Duration : 4 to 5 years
Product Size : 1 million source lines
• It consists of several major subsystem each of which forms a large system.
• The subsystem have complex,interactions with one another and with other separate we
developed system.
• Tele communication and multi tasking.
• It includes large OS, large database system and military commandor and control system.
 Extremely large Projects:

5 Class Notes Prepared By PDS

 No.of Programmers : 2000 to 5000
Duration : 5 to 10 years
Product Size : 1 million to 10 million source lines
• It consist of several very large subsystem.
• It involves real time processing,tele communications,multi tasking and distributed
processing.
Example - Air traffic control,military commandor control system.
 How Programmers Spend Their Time:

Quality & Productivity Factors

• Development and maintenance of software product are complex task.
• There is a fundamental difference between writing a small programs for PC and
developing or modifying a software product.
• Software Quality and programmer productivity can be improved by improving the
process used to develop and maintain software products.
 Individual Ability:
• Production and maintenance of software products are labour intensive activities.
• Productivity and Quality are direct functions of individual ability and effort.
There are two aspects of ability
-Familiarity of the individual with the particular application area.
-Individual ability is a primary factor in quality and productivity.
 Team communication:
• Programming has regarded as an individual and private activity.
• Many of the recent innovations in software Engineering such as design, reviews and
code reading exercise have the goals of making software more visible and improving
communications among programmers.
• Increasing product size results in decreasing programmer productivity due to the
increased complexity of interactions among program components.
• Due to this increased communication is required among programmers, managers and
customers.
From Brooks observation:
No of communication path among programmers = n(n-1)/2
Where n=no of programmers.
Brooks law:

6 Class Notes Prepared By PDS

 “Adding more programmers to a late project may make it later”
 Product complexity:
There are 3 levels of product complexity.
 Application Program
• It includes scientific and data processing routines written in a high level language such
as COBOL,FORTRAN,C,C++.
• Application programs have the highest productivity and the system programs the lowest
productivity.
• Application programs at a rate of 25-100 times of system programs.
 Utility Program
• It includes compilers,Assemblers,linkage Editors and loaders.
• They may be written in high level language or Assembly language.
• Utility programs can be produced at a rate of 5-10 times of system programs.
 System Level Programs:
• It includes data communication packages real time process control system ,OS routines
in any languages.(i.e)high level or assembly.
 Appropriate Notations:
• Appropriate notations provide vehicles of communication among project personnel.
• It introduces the possibility of using automated software tools to manipulate the
notations and verify proper usage.
 Systematic Approaches:
• In every field there are certain accepted procedures and techniques
• A Single approach to software development and maintenance will not be adequate to
cover all situations.
• In the evaluation of software engineering it is not clear which of the various approaches
to software development should be used in which situation.
 Change Control:
• Requirements can also change due to poor understanding of the problem are external
economic and political factors beyond the control of the customers or developers.
• Notations and procedures provide the ability to trace and access the impact of proposed
changes are necessary to make visible the true cost of apparently small changes to
source code.
• Use of appropriate notations and techniques makes control change possible without
degrading the quality of work products.
• Planning for software project must include plans for change control.
 Level of Technology:
• It include factors such as programming language.
 Machine Environment
• The machine environment includes a set of hardware and software facilities for
developing and maintaining a software product.
 The Programming Practices
• Modern Programming languages provide improved facilities for data definition and data
usage.

7 Class Notes Prepared By PDS

 Software tools

 Level of Reliability:
• Every software product must possess basic level of reliability.
• Extreme reliability is gained only with great care in analysis,design,design
implementation,system testing and maintenance of software product.
• Both human and machine resources are required to obtained increased reliability.
 Problem Understanding:
• Failures to understand the true nature of the problem to be solved is a common and
difficult issue.
• Often the customer does not truly understand nature of the problem.
• Often the software engineering does not understand the application area and has
trouble communicating with the customer because of differences in educational
backgrounds view the points and technology.
• Careful planning customer interviews, task observations and prototyping, a preliminary
version of the user’s manual and precise product specification can increase both
customer and developer understanding of the problem to be solved.
 Available Time:
• A software project requiring 6 programmer-months of effort can be completed by 1
programmer in 6 months or by 6 programmers in 1 month.
• Software projects are sensitive not only to total effort but also to ellapse time and the no
of people involved.
• Utilising 6 programmers for 1 month will be less effective than using 1 programmer for
6 months.
• This is because the learning curve for 6 programmers on an 1 month schedule will
occupy a large percentage of the elapsed time and because the effort required for co-
ordination and communication among 6 programmers.
 Required Skill:
 Software Engineering requires a vast range of skills.
 Good Communications
 Knowledge of application area
 Requirement definition and design
 Problem solving skills
 Implementation of software (i.e)Good programming knowledge, no syntax error
 Debugging and test plans
 Inter personnel communication skill.
 Facilities and Resources:
• Work related factors such as Good machine access and quiet place to work are more
important.
• Software project managers must be effective in dealing with the factors that motivate
the programmers to maintain high note on product quality, programmer productivity
and high job satisfaction.
 Adequacy of Training:
 Express oneself clearly in English
 Develop and Validate software requirements and design specifications.
 Work within application area
 Perform software maintenance

8 Class Notes Prepared By PDS

 Perform economic analysis.
 Work with project management techniques
 Work in groups
 Management Skills:
• Many of the problems in software project management are unique.
• Managers experienced in management of computer hardware projects find software
project management to be difficult.
• This is due to the differences in design methods, notations and development tools.
• Many Organisations offer project management training to software engineers to prepare
them for project management task.

 Raising Expectations:
There are two interrelated aspects of raising expectations
1. How much functionality, reliability and performance can be provided by a given
amount of development effort.
2.Issues of fundamental limitations of software technology.
 Appropriate Goals:
• Primary Goal of software engineering is to development of software products
for their intended use.
• Every software product must provide optimal level of
1. Generality (Broad View)
2. Reliability (Trustworthiness)
3. Efficiency
 Managerial Issues:
Success of Software project involves
 Technical Activities
 Managerial Activities
Managers Control
1.Resources
2.Environment
• Important managers responsibility
– Software product delivered on time
– Software working according to customer’s wish
– Software within cost estimates
 Other managerial responsibility:
– Business Plans
– Recruiting customers
– Developing Marketing Strategies
– Recruiting and training employees
 Important Problems:
• Planning is poor
• Selection for project managers are poor (i.e) Procedures and Techniques
• Description of project is poor
• Estimation of resources for software project is poor
• Success criteria is inappropriate

9 Class Notes Prepared By PDS

• Decisions rules are poor(for selecting the proper organizational structure, correct
management techniques )
• Procedures ,methods and techniques are not readily available.
 Methods for solving these problems:
• Analyze the data from previous software project to find effective methods
• Define objectives,quality
• Establish success priority criteria
• Develop accurate cost and schedule that are accepted by management and customer
• Selection of project managers
• Specific work assignments to software developers
Planning A Software Product
 Introduction:
 Defining the problem
 Developing the solution strategy
 Planning the Development Process
 Goals & Requirements:
• Goals can be formulated using concise statement, constraints.
• Goal apply to both development process and work product.
• It can be either qualitative or quantitative.
• Every development process Should provide product on time & within cost estimates .
• Opportunities for project personnel to learn new skill.
 Qualitative process goal:
1. The development process should enhance the professional skills of quality assurance
personnel.
2. The system should be delivered within 12 months.
3. The system should make users' jobs more interesting.
4. The system should reduce the cost of a transaction by 25 percent.
 Qualitative requirements:
1. Accuracy shall be sufficient to support mission.
2. System shall provide real-time response.
3. System shall make efficient use of primary memory.
4. System shall be 99 percent reliable

10 Class Notes Prepared By PDS

 Developing A Solution Strategy
• A Solution Strategy is a general statement concerning the nature of possible solutions.
• A solution strategy is feasible if the project goals and requirements can be satisfied
within the constraints of available time, resources, and technology using that strategy.
• Constraints prescribe the boundaries of the solution space.
• Feasibility analysis determines whether a proposed strategy is possible within those
boundaries.
• Some iteration and trade-off decisions may be required to bring feasibility and
constraints into balance.

Planning The Development Process

• Different models are used for various software product.
• A life cycle model that is understood and accepted by all concerned parties improves
project communications and project manageability , resource allocations, cost control
and product quality.
• Life cycle model discussed here include
1. Phased Model
2. Cost Model
3. Prototype Model
4. Successive Version Model
 The phased lifecycle model:
• Series of successive activities.
• Requires well defined input, process and results in well-defined output.
• Resources is required to complete each phase.
• Application of explicit methods, tools and techniques.

11 Class Notes Prepared By PDS

  Analysis consist of two sub phases
– Planning
– Requirements definition.
1. The products of planning are
 System definitions:
• Expressed in English or some other language.
• It includes charts, figures, graphs, tables and equations.
 Project plan:
• Organizational structure.
• Basic development schedule, resource estimate, staffing requirements, tools and
techniques to be used.
• Time and cost are basically calculated because it is not possible to estimate exactly
without doing basic design.
2. Requirements definitions:
• It includes basic functions of software components in hardware, software and people
subsystem.
 Design phase:
Design phase consist of
1. Architectural design:
• It involves identifying the software components dividing them into software modules
and conceptual data structures, specifying interconnection among components.
2. Detailed design
• It is concerned with the details of “how to” Package the processing modules.
• To Implement the processing, algorithm, data structures and interconnection among
modules.
 Implementation phase:
• It involves translation of design specification into source code and debugging,
documentation and unit testing of source code.
Unit Testing is a level of software testing where individual units/ components of a
software are tested. The purpose is to validate that each unit of the software performs as
designed.
 System testing:

12 Class Notes Prepared By PDS

1. Integration testing:
• Developing a strategy for integrating the software components into a function requires
careful planning so that modules are available for integration when needed.
2. Acceptance testing:
• It involves planning an execution of various type of test that software system satisfied
requirements documents.
• After getting the acceptance from the customer software system of released for
production work and maintenance phase.
 Maintenance Phase:
It Includes
1. The enhancement of capabilities.
2. Adaptation of software to new processing environment.
3. Correction of software bugs.
 The Cost Model
• This model is used specify the cost of performing various activities in a Software project.
• The cost of conducting a Software project is the sum of the cost involved in conducting
each phase of the project.
The cost involved each phase include:
• The cost of performing the process
• Preparing the products of the phase.
• Plus the cost of verifying the product of the present phase are complete and consistent
with the previous phase.
• Cost of producing system definition and project plan = performing planning functions
and preparing documents+ cost of verifying the system definition and project plan.

13 Class Notes Prepared By PDS

 • Cost of SRS= Cost of requirements definition and document + Cost of modifying system
definition and project plan + Cost of verifying SRS is complete and consistence.
• Cost of design= Cost of preparing design specification and test plan+ Cost of modifying
and correcting the system definition, project, SRS+Cost of verifying design
• Cost of product implementation= Cost of implementing documenting, debugging and
unit testing of source code+ Cost of users manual, verification plan, maintenance
procedure, initialization and training instructions+ Cost of modifying and correcting
system definition, project plan,SRS, design specification, verification plan+the Cost of
verifying the implementation is complete and consistent.
• Cost of system test= Cost of planning and conducting the test+ Cost of modifying and
correcting the source code+ Cost of verifying the test.
• Cost of maintenance Software= Cost of performing product enhancement +making
adaptation to new processing requirements and fixing bugs.
 The Prototype Lifecycle Model
• A Prototype is a mock up or model of the Software product.
• It exhibits limited functional capabilities , low reliability and inefficient performance.
There are several reasons for developing a prototype.
• To illustrate input data formats , messages , reports and interactive dialogues for
customer.
• To explore technical issues in the proposed product.
•

14 Class Notes Prepared By PDS

 • In situations where the phased model of AnalysisDesignImplementation is
not appropriate.
• The phased model is applicable when it is possible to write a reasonable complete set of
specification for software product.

 Successive Versions

• Product development by the method of successive

versions is an extension of prototyping.
• In which an initial products skeleton is refined in to
increasing the level of capabilities.
• It illustrates the analysis phase followed by
interactive design, implementation and assessment
of successive version.
• The dashed line indicates that the assessment of
version I may indicate the need for the further
analysis before designing version I+1.
• Version I is the prototype version of the software
product.
• Versions 1 through N of the product or designed
prior to any implementation activities.
• The dashed line indicates that implementation of the
Ith version may reveal the need for further analysis
and design before proceeding with implementation
of version I+1.

Planning An Organizational Structure

• During the lifetime of a software product various task must be performed.
• The task include planning , product development , services , publications , quality
assurance , support and maintenance.
 Project structures
 Project format
• It involves assuming a team of programmers.
Project team members do
1. Product definition 4. Test it
2. Design the product 5. Conducts Project review
3. Implement it 6. Preparing supporting document.

 Functional format:
• In this approach a different team of programmers perform each phase of the Project.
• Functional format involves 3 teams
1. An analysis team.
2. A design team and implementation team.

15 Class Notes Prepared By PDS

 3. Test formatting and maintenance team.
 Matrix format
• In this format each of the functions has its own management team.
• This format involves a group of specialist personnel concerned only with that function.
• Each development project has a project manager concerned only with that Project.
• The Project manager generates and reviews documents.
• Each functional group participate in each Project
eg: software development team members belongs to the development function similarly testing
belong the testing function.
 Programming team structure:
• Every programming team must have an internal structure.
• Team structure depends on the nature of the Project and the product.
Basic team structure includes
 Democratic team
• All team members participate in all decisions.

 The chief programmer team:

• The chief programmer designs , implements the critical path of product & makes all
major decisions.
• The programmers write code , debug and perform unit testing.
• The librarian maintains program listings , design documents , test plans ect.
• The backup program consult serves on various technical problems.

 Hierarchical team:
• In combines the aspects of the democratic team and chief programmer team.
• Each team should be limited to not more than 5 or 17 members for effective
coordination and communication.

16 Class Notes Prepared By PDS

 Other Planning Activities
 Configuration management:
• Concerned with controlling changes in the work products.
• Accounting for the status of the work products
• Maintaining the program support library
 Quality assurance:
• Develops and monitors the Project standards.
• Performs audits.
• Develop and performs acceptance test.
 Planning for independent verification and validation:
• Verification makes sure that various work products are complete and consistence.
• An external organization may verify that the design specifications are complete and
consistence.
• Source code is complete.
• Planning and execution of test cases.
UNIT-II

Software Cost Estimation Techniques

• Software cost estimates are based on past performance
• Cost estimates can be made either (i)Top Down (ii) Bottom-up
 Top-down: Focus on system level cost such as system level cost, quality assurance ,
training and publications.
 Bottom up: Focus on the cost to develop each module are subsystem & combined to
arrive at an overall estimate.
1) Expert Judgement (Top Down)
• Most widely used cost estimation techniques(top down)
• An expert might arrive at a cost estimate in a following manner.
i. To develop a process control system
ii. It is similar to one that was developed last yr in 10 months at a cost of one
million dollar.
iii. The previous system developed was the same
iv. Same computer and controlling devices and many of the same people are
available to develop the new system therefore 20% of the estimate is reduced
v. Resume of the low level code from the previous reduces the time and cost
estimates by 25%
Advantage: Experience
2) Delphi Cost Techniques estimation (Top Down)
• This technique was developed at the R & Corporation in 1948

17 Class Notes Prepared By PDS

 • This technique can be adapted to software estimation in the following manner
1. A co-ordinator provides each estimator with a s/m definition & an estimation form.
2. Estimators study the document and complete their estimates
3. They ask questions to the co-ordinator but they wont discuss with one another
4. The co-ordinator prepares and distributes a summary of the estimators response
5. The estimators complete another estimate .
6. The process is iterated for as many as required
3) Work down break structure (Bottom up)
• A bottom-up estimation tool
• WBS is a hierarchical chart that accounts for the individual parts of the system
• WBS chart can indicate either product hierarchy or process hierarchy
 Process Hierarchy:
• It identifies the work activity and relationship among those activities
• Using WBS cost are estimated by assigning cost to each individual component in the
chart and summing the cost
 Product Hierarchy:
• Identifies the product components and indicates the manner in which the components
are interconnected.
• WBS are the most widely used cost estimation Techniques

4) Algorithmic Cost Model (Bottom up)(COCOMO)

• Algorithmic cost estimators compute the estimated cost of software system·
• The constructive cost model (COCOMO)is an algorithmic cost model described by
Boehm.
• In COCOMO model the equation calculates the programmer month and development
schedule are used for the program unit based on the number of (DSI)
• Effort multipliers are used to adjacent the estimate for product attribute , computer ,
customer and project attribute.

18 Class Notes Prepared By PDS

 STAFFING-LEVEL ESTIMATION
• The number of persons required throughout a software development project is not
constant.
• In 1958, Norden observed that research and development projects follow a cycle of
planning, design, prototype, development and use with the corresponding personnel
utilization illustrated in Figure 3.6.

• The Rayleigh curve is specified by two parameters: td, the time at which the curve
reaches its maximum value.
• And K, the total area under the curve, which represents the total effort required for the
project.
• The td corresponds to the time of system testing and product release for many software
products.
• Approximately 40 percent of the area under the Rayleigh curve is to the left of td and 60
percent is to the right.

• In 1976, Putnam reported that the personnel level of effort required throughout the life
cycle of a software product has a similar envelope.
• Putnam subsequently studied 50 Army software projects and 150 other projects to
determine how the Rayleigh curve can be used to describe the software life cycle.

19 Class Notes Prepared By PDS

 ESTIMATING SOFTWARE MAINTENANCE COSTS
• Software maintenance typically requires 40 to 60 percent, and in some cases as much as
90 percent.
• A widely used rule of thumb for the distribution of maintenance activities is 60 percent
for enhancements, 20 percent for adaptation, and 20 percent for error correction.
• In a survey of 487 business data processing installations, Lientz and Swanson
determined.
• The typical level of effort devoted to software maintenance was around 50 percent of
total life-cycle effort.
• And that the distribution of maintenance activities was 51.3 percent for enhancement,
23.6 percent for adaptation, 21.7 percent for repair, and 3.4 percent for other.
• These percentages are further broken down in Table 3.9.

Software Requirements Definition

 Introduction
• In contrast, the Software Requirements Specification is a technical specification of
requirements for the software product.
• The goal of software requirements definition is to completely and consistently, specify
the technical requirements for the software product in a concise and unambiguous
manner, using formal notations as appropriate.
• The Software Requirernents Specification is based on the System Definition.
• High-level requirements specified during initial planning are elaborated and made
more specific in order to characterize the features that the software product will
incorporate.
Software Requirements Specification
• Section 1 & 2 of the requirement document presents the overview of product features
and summarizes the processing environment of development, operation and
maintenance of the product.
• Section 3 includes user display and report formats a summary of user commands , DFD
and Data Dictionary.

20 Class Notes Prepared By PDS

• The DFD specifics data sources & data sinks transformation to be performed on data and
the flow of data between data source and sinks.

• The data flow diagram is formally illustrated in fig 4.2

• The data source & sinks are depicted by shaded rectangles.
• Transformation by ordering rectangles & data store by open ended rectangle.

• Section 4 defines the functional requirements for the software product.

• Functional requirements are typically expressed in relational and state oriented
notations that specify relationships among inputs, actions, and outputs.
• In section 5 Performance characteristics such as response time for various activities,
processing time for various processes, throughput, primary and secondary memory
constraints, required telecommunication bandwidth, and special items such as
extraordinary security constraints or unusual reliability requirements are specified.
• In section 6 Exception handling, including the actions to be taken and the messages to be
displayed in response to undesired situations or events .
• Section 7 of the Software Requirements Specification specifies early subsets and
implementation priorities for the system under development.
• Section 8 specifies the modification and enhancement.
• Section 9 specifies the acceptance criteria (various test).
• Section 10 contains design hints and guide lines.
• Section 11 specifies cross reference index.

21 Class Notes Prepared By PDS

 • A cross reference directory should be provided to index to find the specific paragraph
numbers in SRS.
• Section 12 provides definition of terms that are unfamiliar to the customers and the
product developers.

FORMAL SPECIFICATION TECHNIQUES

• Functional characteristics of an s/w product are one of the most important
activities in requirement analysis.
• The advantage of formal notation is concise and ambiguous.
• They provide the basis for verification of the resulting s/w product.
Two nations are used to specify the functional characteristics.
 Relational notations include,
1. Implicit equations
2. Recurrence relations
3. Algebraic axioms
4. Regular expressions
 State oriented notations include
1. Decision tables.
2. Even tables.
3. Transition tables.
4. Finite state mechanism.
5. Petrinets.

 Relational notations:
• It is based on the concept of entities and attributes.
• Entities are named elements in a system. Eg: stack, queue
• Attributes are specified by applying functions and relations to the named entities.
• Attributes specify permitted operations on entities, relationships among entities and
data flow between entities.
 Implicit Notation:
• Complete of matrix element which include matrix size ,data element ,algorithm for
computing the inverse and packaging technique for inversion module.
• M x M' = I ± E
• Iimplicit equations state the properties of a solution without stating a solution method.

 Recurrence Relations:
• The recursive part describes the desired value of functions in terms of other values of
the function.
• For eg successive Fibonacci numbers are formed as the sum of previous two Fibonacci
numbers.

• Where the first one is defined as 0 and the second as 1.

• The Fibonacci numbers can be defined by the recurrence:

22 Class Notes Prepared By PDS

• The recurrence relation can be easily transformed into recursive programs.

 Algebraic Axioms:
• Mathematical systems are defined by axioms.
• The axioms specify 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.
• In order to establish valid mathematical system, the set of Axioms must be complete
and consistent.
• Axiomatic specification of the last-in first-out (LIFO) property of stack objects is
specified in Figure 4.3.
• Observe that the type of data elements being manipulated, ITEM, is a parameter in the
specification, and that the specification is representation independent.
• Operations NEW, PUSH, POP, TOP, and EMPTY are named to suggest their purposes
mentioned below:

• The theory of algebraic specification stated in terms of "constructors," "modifiers," and

"behaviors“.
• In Figure 4.3 the constructors are NEW and PUSH.
• POP is a modifier, and TOP & EMPTY behaviors.
• The FIFO properties of queues is specified in figure 4.5

• In Figure 4.5, NEW and ADD are constructor, REMOVE is a modified and FRONT &
EMPTY are behaviors.

23 Class Notes Prepared By PDS

  Regular expressions
• Regular expressions can be used to specify the syntactic structure of symbol strings.
• Regular expressions can thus be viewed as language generators.
•

• Observe that the rule 2,3 and 4 are recursive.

• Examples of regular expression are follows:

• Closure (R1)* denotes zero or more connected series of elements from R1.
 State Oriented Notations
 Decision Tables:
• They are used for recording complex decision logic.

24 Class Notes Prepared By PDS

 • Decision table is segmented into four quadrants
1. Condition stub: It contains all of the conditions being examined.
2. Condition entry : It is used to combine conditions into decision rules.
3. Action stub: It describes the actions to be taken in response to a decision rules.
4. Action entry: It relates decision rules to actions.

• They are used for recording complex decision logic.

•

• Orders are approved if the credit limit is not exceeded or if the credit limit is exceeded
but past experience is good or if a special arrangement has made otherwise the order is
rejected.
 Event Table:
• An Event table is useful for specifying system behaviour when different stimuli results in
different modes of operations.

• A two dimensional event table relates actions to two variables f(M,E)=A.

• ‘M’ denotes the current set of operating conditions.
• ‘E’ is the event of interest and ‘A’ is the action to be taken.
• In the table actions separated by semicolon (A14;A32) denote A14 followed sequentially
by A32.
• Actions separated by commas (A6,A2) denotes concurrent activation of A6 and A2.
• Similarly the (-) specifies no action required.
• ‘X’ indicates an impossible system configuration.

 Transition Tables:
• Transition tables and diagrams can be used to specify the next desired state of a system.
• Transition diagram are alternate representation for Transition tables.

25 Class Notes Prepared By PDS

• In a TD state becomes nodes in a directed graph & transition are represented by arcs
between nodes.
• Arcs are labled with conditions that causes transition.
• Transition tables and diagrams are representation for finite state automata.

 Finite State Mechanism :

• Finite –state mechanism utilize DFD in which the data streams are specified using
regular expressions.
• The actions in the processing nodes are specified using processing tables.
• FSM are useful for specifying high level system behaviour in response to various stimuli.

 Petri Nets :
• Petri Nets in state oriented notations are used for specifying parallelism of operations.
• Concurrent systems are designed to permit simultaneous execution of software
components called task on multiple processors.
• Petri Nets were invented to overcome the limitations of FSM.
• Two types of nodes in a Petri net called places(are marked by tokens) and transition.

26 Class Notes Prepared By PDS

 LANGUAGES AND PROCESSORS FOR REQUIREMENTS SPECIFICATION
• Languages and processors have been developed to permit concise statement and
automated analysis of requirements specifications for software.
• Some specification languages are graphical in nature which are manually applied,
while others are textual which have automated processors.
 PSL/PSA
• The Problem Statement Language (PSL) was developed by Professor Daniel
Teichrow.
• The Problem Statement Analyzer (PSA) is the PSL processor.
The PSL model describes a system as a set of objects, where each object may have
properties, and each property may have property
• Here Objects may be interconnected the connections are called relationships.
In PSL, system descriptions can be divided into eight major aspects:
 System input/output flow:
• It deals with the interaction between a system and its environment.
System structure:
• It is concerned with the hierarchies among objects in a system.
Data structure:
• It includes all the relationships that exist among data and manipulated by a system as
seen by the users of the system.
Data derivation:
The data derivation aspect of the system description specifies which data objects are
involved in particular
System size and volume:
• The system size and volume aspect is concerned with the size of the system and those
factors that influence the volume of processing required.
System Dynamics:
• The system dynamics aspect of a system description presents the manner in which the
system "behaves" over time.
Project management:
• The project management aspect requires that project-related information be provided.
• This involves identification of the people involved, their responsibilities, schedules, cost
estimates, etc.
• The Problem Statement Analyzer (PSA) is an automated analyzer for processing
requirement stated in PSL
The structure of PSA illustrated in Figure

27 Class Notes Prepared By PDS

 • PSA operates on a data base of information collected from a PSL description.
• The PSA system can provide reports in four categories:
Data-base modification reports
• It list the changes that have been made since the last report, these reports provide a
record of changes for error correction and recovery.
Reference reports
• Reference reports include the Name List Report, which lists all the objects in the data
base with types and dates of last change.
Summary reports
• The Summary reports present information collected from several relationships.
Analysis reports
• Analysis reports include the Contents Comparison Report, which compares the similarity
of inputs and outputs.
 RSL/REVS
• The Requirements Statement Language (RSL) was developed by the TRW Defense and
Space Systems Group for real-time software systems.
• The Requirements Engineering Validation System (REVS) processes and analyzes RSL
statements.
RSL has four primitive concepts:
(i)Elements- which name objects
(ii) Attributes- which describe the characteristics of element relationships which
describe binary relations between elements and
(iii)Structures- which are composed of nodes and
(iv)Processing steps.
• The fundamental characteristic of RSL is the flow-oriented approach.
• Flows are specified in RSL as requirement network(R-NET).
• The Requirements Engineering and Validation System (REVS) operates on RSL
statements.
REVS consists of three major components:
• A translator for RSL
• A centralized data base, the Abstract System Semantic Model (ASSM)
• A set of automated tools for processing information in ASSM
• REVS is a large complex software tool.
• Use of the REVS system is cost- effective only for specification of large complex real-time
systems.

28 Class Notes Prepared By PDS

  Structured Analysis and Design Technique (SADT)*
• The SADT language is called the Language of Structured Analysis (SA).
• Two basic types of SA diagrams are the activity diagram (actigram) and the data
diagram (datagram).
• On an actigrams the nodes denote activities and the arcs specify data flow between
activities.
• Datagrams specify data objects in the nodes and activities on the arcs.
• Figure 4.2a and b illustrates the formats of actigram and datagram nodes.

• It is important to note that four distinct types of arcs can be attached to each node.
• Arcs coming into the left side of a node carry inputs and arcs leaving the right side of a
node convey outputs.
• Arcs entering the top of a node convey control and arcs entering the bottom specify
mechanism.
• In an activity diagram the inputs and outputs arc data flows and the mechanisms arc
processors (mechanical or human).
• In a data diagram the input is the activity that creates the data object and the output is
the activity that uses the data object.
 Structured System Analysis (SSA)
• There are four basic features in SSA: data flow diagrams, data dictionaries. processing
logic representations and data store structuring techniques.
• SSA DFD are similar to SADT actigrams but an additional notation is used to show data
stores.
• A data dictionary is used to define and record data elements and processing logic
representations, such as decision tables and structured English, are used to specify
algorithmic processing details.
• Processing logic representations an used to precisely specify processing sequences that
are understandable to customers and developers.
 Gist
A specification is composed of three parts:
• A specification of object types and relationships between these types.
• A specification of actions which define transitions between possible states.
• A specification of constraints on states and state transitions.
• Preparing a Gist specification involves several steps:
1. Identify a collection of object types.
2. Identify individual objects (values) within types.
3. Identify relationships to specify the ways in which objects can be related to one
another.
4. Identify types and relationships that can be in terms of other types and relations.

29 Class Notes Prepared By PDS

 5. Identify static constraints on the types and relationships.
6. Identify actions that can change the state of the process in some way.
7. Identify dynamic constraints. Typical dynamic constraints include restrictions
prohibiting changes in certain relationships between objects.
8. Identify active participants and group them into classes such that common
actions are formed by the participants in a class.

UNIT-III
Fundamental Design Concepts
 Introduction:
• There are 3 distinct types of activities in software design:
• External , (Architectural & Detailed design) Internal design.
• E.D involves planning and specifying observable characters of software product.
• Fundamental concepts of software design include
 Abstraction
• It is the intellectual tool that allows us to deal with concepts apart from particular
instances.
• During software design it allows us to organize considerations until functional
characteristics data streams and stores have been established.
• Three widely used mechanism are Functional , Data and Control abstraction.
 Information Hiding
• When a software system is designed using information hiding approach.
• Each module in the system hides the internal details of its processing activities.
• Here modules communicate with well defined interfaces.
 Structure
• The use of structuring permits decomposition of a large system into smaller, more
manageable units with well-defined relationships to the other units in the system.
• The most general form of system structure is the network.
• A computing network can be represented as a directed graph, consisting of nodes and
arcs.
• The nodes can represent processing elements that transform data and the arcs can be
used to represent data links between nodes.
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.
• A hierarchical ordering relation can be represented as an acyclic, directed graph with a
distinguished node that represents the root entity.

30 Class Notes Prepared By PDS

• Hierarchical structures may or may not form tree structures.
• The diagrams illustrated in Figure 5.4a and b are called structure charts.
• Directly recursive routines (those that invoke themselves) can be indicated on a
structure chart by placing closed arcs on the nodes for those routines.
• Indirectly recursive routines (ABCA) Violate the hierarchical structuring rule, and
should generally be avoided.
• Allowable exceptions include mutually recursive routines and coroutines(A B).
• Figure 5.4a and b illustrate a directed, acyclic graph and a tree structure respectively.
• Note that in a tree there is a unique path from the root to each node.
• In an acyclic, directed graph there may be more than one path from the root to a node.

31 Class Notes Prepared By PDS

 Modularity
• There are many definitions of the term Module.
• They range from a module is a FORTRAN subroutine to a module is an Ada package to a
module is a wore assignment for an individual programmer.
• Modular systems consist of well- defined, manageable units with well-defined interfaces
among the units.
• Modularity enhances design clarity which in turn eases implementation , debugging,
testing, documentation & maintenance of software product.
 Concurrency
• Concurrent systems have independent processes that can be activated simultaneously if
multiple processors are available. On a single processor, concurrent processes can be
interleaved in execution time. This permits implementation of time-shared,
multiprogrammed and real-time systems.
• Problems unique to concurrent systems includes
Deadlock is an undesirable situation that occurs when all processes in a computing
system are waiting for other processes to complete some actions so that each can
proceed.
Mutual exclusion is necessary to ensure that multiple processes do not attempt to
update the same components of the shared processing state at the same time.
Synchronization is required so that concurrent processes operating at differing
execution speeds can communicate at the appropriate points in their execution
histories.
 Verification
• A design is verifiable if it can be demonstrated that the design will result in an
implementation that satisfies the customer's requirements.
• This is typically done in two steps:
(1) verification that the software requirements definition satisfies the customer's
needs (verification of the requirements)
(2) verification that the design satisfies the requirements definition (verification
of the design).
 Aesthetics (framing rules)
• It is difficult to list objective criteria for evaluating the aesthetic factors in a software
product but an aesthetically pleasing product is easily recognized.

Modules & Modularization Criteria

• Architectural design has the goal of producing well-structured modular software
systems.
• In this section of the text, we consider a software module to be a named entity having
the following characteristics
1. Modules contain instructions, processing logic, and data structures.
2. Modules can be separately compiled and stored in a library.
3. Modules can be included in a program.
4. Module segments can be used by invoking a name and some parameter.
5. Modules can use other modules.
• Examples of modules include procedures, subroutines and Functions functional groups
of related procedures, data abstraction groups ,utility groups and concurrent processes.

32 Class Notes Prepared By PDS

 Coupling and cohesion
 Coupling
• Coupling and cohesion were first described by Stevens, Constantine, and Myers as part
of the "structured design"
Def : coupling is the degree of interdependence between software modules
• Communication between modules involves passing of data, passing elements of control
(such as flags, switches, labels, and procedure names), and modification of one module's
code by another module.
• The degree of coupling is Lowest for DATA COMMUNICATION, Higher for CONTROL
COMMUNICATION and Highest for MODULES THAT MODIFY OTHER MODULES.
• Coupling between modules can be ranked on scale of strongest (least desirable) to
weakest (most desirable) as follows:

o Data coupling involves the use of parameter lists to pass data items between routines.
o Stamp coupling is more desirable than common coupling because fewer modules will
have to be modified if a shared data structure is modified.
o Control coupling involves passing control flag between modules so that one module
controls the sequence of processing step in another module.
o Common coupling modules are bound together by global data structures.
o Content coupling occurs when one module modifies local data values or instructions in
another module. They can occur in assembly language programs.
• The most desirable form of coupling between modules is a combination of stamp and
data coupling.

 Cohesion
• Def: It refers to the level of strength with which different components of a software
program are inter-related with each other.
• Cohesion of elements occurs on the scale of weakest (least desirable) to strongest (most
desirable) in the following order
• Coincidental cohesion occurs when the elements within a module have no apparent
relationship with another.
• Logical cohesion implies some relationship among the elements of the module as for
example in a module that performs all input and output operations.
• Temporal cohesion here all elements are executed at one time and no parameters are
required to determine which elements to execute.
• A typical example of temporal cohesion is program initialization.
• Informational cohesion of elements in a module occurs when the module contains a
complex data structure and several routines to manipulate the data structure.
• Communicational cohesion Here the elements of a module possessing refers to the
same set of input and/or output data.
• Sequential cohesion of elements occurs when the output of one element is the input for
the next element.
• For example. "Read Next Transaction and Update Master File" is sequentially bound.
• Functional cohesion is a strong and hence desirable type of binding of elements in a
module because all elements are related to the performance of a single function.
• Examples are "Compute Square Root" , "Obtain Random Number" and "Write Record to
Output File.“

33 Class Notes Prepared By PDS

 Other Modularization Criteria
• Additional criteria for deciding which functions to place in which modules of a software
system include:
Hiding difficult and changeable design decisions.
Limiting the physical size of modules.
Structuring the system to improve observability and testability.
• For each software product the designer must weigh these factors and develop a
consistent set of modularization criteria to guide the design process.

Design Notations
• The design specativation can be categorized into three levels:
a. External design specifications which describe the external characteristics of a
software system.
b. Architectural design specifications which describe the structure of the system.
c. Detailed design specifications which describe control flow, data representation.
and other algorithmic details within the modules.
• Notations used to specify the external characteristics, architectural structure, and
processing details of a software system which are represented below.

 DFD
• A data flow diagram are directed graphs in which the Nodes specify processing activity
and Arcs specify data item transmitted between the processing nodes.
• A data flow diagram might specify the data flow between individual statements.
• They can be expressed using Informal Notations.

34 Class Notes Prepared By PDS

 Structuring Charts:
• They are used during Architectural Design to document Hierarchical Structure,
Parameter and Interconnections in a system.
• The chart can be argument with module–by-module specification of input/output
parameters.
• The structure of Hierarchical system can be specified using a structure chart is
illustrated in figure given below.

 HIPO Diagram:
• The Hierarchy-Process-Input-Output was developed at IBM for Top-down software
development.
• A set of HIPO diagram contains visual table of contents.
• The visual table of content is a directory to the set of diagrams in the package.

35 Class Notes Prepared By PDS

• Overview diagram specify the functional processes in a system.
• Each overview diagram describes the Input , processing steps and outputs for the
function being specified.
• An overview diagram can point to several subordinate detail diagrams as described.
• The format is illustrated in the given figures.

 Procedure Templates
• The procedure interface and pseudocode can be expanded directly into source code
during product implementation.
• In the early stages of Architectural Design only the information in level 1 need be
supplied.
• As Design progresses, the information on levels 2, 3 and 4 can be included in successive
steps.
• Procedure interface provide a natural transition from Architectural to Detailed design
and from Detailed design to Implementation.
• The format of a procedure interface specification is illustrated in Figure 5.10.

 Pseudocode
• Pseudocode notation can be used in both the Architectural and Detailed design phases.
• Like flowcharts, pseudocode can be used at any desired level of abstraction.
• Using pseudocode the Designer describes system characteristics using short concise,
English language phrases that are structured by key words such as If-ThenElse, While-
Do.
• Pseudocode can replace flowcharts and reduce the amount of external documentation
required to describe a system.

 Structured Flowcharts:
• The structured flowcharts may be preferred in situations where clarity of control flow
is to be emphasized.
• Because structured flowcharts are logically equivalent to pseudocode, they have the
same expressive power as pseudocode.

36 Class Notes Prepared By PDS

• Both can be used to express any conceivable algorithm.
• The single entry, single exit property allows hierarchical nesting of structured flowchart
constructs to document a design in top-down fashion.

 Structured English
• Structured English can be used to provide a step-by-step specification for an algorithm.
• Like pseudocode, structured English can be used at any desired level of detail.
• An example of using structured English for software specification is provided in Figure
5.9, where it is used to specify the processing plan of the Hipo diagram.

 Decision Tables:
• They can be used to specify complex decision logic in high level software
specification.(ch 4)
• They are also useful for specifying algorithmic logic during detailed design.

DESIGN TECHNIQUES
•The design techniques involves developing the conceptual view of the system,
establishing system structure ,decomposing higher level function into subfunctions
and specifying algorithmic details.
• The D.T is basically based on Top down or Bottom up approach strategies.
• In the Top Down approach attention is based on global aspects,
• like customer needs, user intefaces & overall nature of the problem being solved.
• In the Bottom Up approach the designer attempts to identify set of primitives
objects, actions and relationships that will provide the basis for the solution.
• Several techniques have been developed for software design often called "Design
Methodologies"
 Stepwise refinement
• Stepwise refinement is a top-down technique for decomposing a system from high-level
specifications into more elementary levels.
• It is also known as "stepwise program development" and “successive refinement”.
• stepwise refinement involves the following activities:
• Decomposing design decisions to elementary levels.
• Isolating design aspects that are not truly interdependent.
• Postponing decisions concerning representation details as long as possible.

37 Class Notes Prepared By PDS

• Carefully demonstrating that each successive step in the refinement process is a faithful
expansion of previous steps.
 Levels of Abstraction
• Levels of abstraction was originally described by Dijkstra as a Bottom-up Design
technique in which an operating system.
• it was designed as a layering of hierarchical levels starting at level 0 (processor
allocation, real-time clock interrupts) and building up to the level of processing
independent user programs.
• Each level of abstraction performs a set of services for the functions on the next higher
level of abstraction.
 Structured Design
• Structured design was developed by Constantine as a top-down technique for
architectural design of software systems.
• The basic approach in structured design is systematic conversion of data flow diagrams
into structure charts.
• As discussed in previous section ‘coupling’ measures the degree to which two distinct
modules are bound together, and ‘cohesion’ is a measure of the relationship of elements
within a module to one another.
• The first step in structured design is review and refinement of the data flow diagram
developed during requirements definition and external design.
• The second step is to determine whether the system is transform-centered or
transaction- driven, and to derive a high-level structure chart based on this
determination.
• In a transform-centered system, the data flow diagram contains Input, Processing, and
Output segments that are converted into Input, Processing, and Output subsystems in
the structure chart.
• The situation is illustrated in Figure 5.14.

38 Class Notes Prepared By PDS

• In summary, the primary benefits of structured design are:
1. The use of data flow diagrams focuses attention on the problem structure. this follows
naturally from requirements analysis and external design.
2. The method of translating data flow diagrams into structure charts provides a method
for initiating architectural design in a systematic manner.
3. Data dictionaries can be used in conjunction with structure charts to specify data
attributes and data relationships.
4. Design heuristics such as coupling and cohesion, and scope of effect and scope of control
provide criteria for systematic development of architectural structure and for
comparison of alternative design structures.
5. Detailed design techniques and notations such as successive refinement, HIPO diagrams,
procedure specification forms, and pseudocode can be used to perform detailed design
of the individual modules.

 Integrated Top-Down Development

• Integrated top-down development integrates design, implementation, and testing.
• Using integrated top-down development, design proceeds top-down from the highest-
level routines
• They have the primary function of coordinating and sequencing the lower-level
routines.
• The purpose of procedure MAIN is to coordinate and sequence the GET. PROCESS and
PUT routines.
• These three routines can communicate only through MAIN: similarly, SUB1 and SUB2
(which support PROCESS), can communicate only through PROCESS.

39 Class Notes Prepared By PDS

• The advantage of the integrated top-down approach is distribution of system integration
across the project, the interfaces are established, coded, and tested as the design
progresses.
• The disadvantage of the integrated top-down approach is that early high level design
decisions may have to be reconsidered when the design progresses to lower levels.
• This may require design backtracking and considerable rewriting of code.
 Jackson Structured Programming
• Jackson Structured Programming was developed by Jackson as a systematic technique
for ‘mapping the structure of a problem’ into a ‘program structure’.
• The mapping is accomplished in three steps:
1. The problem is modeled by specifying the I/O data structures using tree structured
diagrams.
2. The I/O model is converted into a structural model for the program by identifying points
of correspondence between nodes in the I/O trees.
3. The structural model of the program is expanded into a detailed design model that
contains the operations needed to solve the problem.
• I/O structures are specified using a ‘graphical notation’ to specify data hierarchy,
sequences of data, repetition of data items, and alternate data items.
• To explain the concept an example of program structure is illustrated below where
there are two symbolic notations used.
– *  it represents 0 (or) more occurrence.
– O  passing the control either to node1 (or) node2.

Detailed Design Considerations

• Detailed design is concerned with specifying algorithmic details, concrete data
representations, interconnections among functions, data structures and packaging of the
software product.
• Detailed design is strongly influenced by the implementation language.
• Implementation addresses issues of programming language syntax coding style,
internal documentation, insertion of testing and debugging probes into the code.
• Detailed design permits design of algorithms and data representations at a higher level
of abstraction and notation than the implementation language provides.

40 Class Notes Prepared By PDS

• Detailed design also provides a vehicle for design inspections, structured walkthroughs
and the Critical Design Review.
• Notations for detailed design include HIPO diagrams, pseudo code, structured English,
structured flowcharts, data structure diagrams and physical layouts for data
representations.
• Product packaging is an important aspect of Detailed Design.
• Detailed design should be carried to a level where each statement in the design notation
will result in a few (less than 10) statements in the implementation language.

Distributed And Real-time System Design

• Many of the popular “Design Methodologies" were developed as Design Techniques.
• These methods support concepts such as hierarchical decomposition, modularity,
information hiding and data abstraction.
• These design concepts are important for real-time and distributed systems.
• Major issues to be addressed in designing a distributed system include specifying the
topology of the communication network.
• Establishing rules for process communication and synchronization.
• The design of distributed systems is further complicated by the need to allocate
network functionality between hardware and software components.
• The Real-time Systems must provide specified amounts of computation within fixed
time intervals.
• Real-time systems typically sense and control external devices, respond to external
events and share processing time between multiple tasks.
• A Real-time Network for process control may consist of several minicomputers and
microcomputers connected to one or more large processors.
 Test Plans
There are four types of tests that a software product must satisfy:
 Functional Test:
• FT specifies typical operating conditions , typical input values and typical expected
results.
• They should also be designed to test boundary conditions just inside or just beyond the
boundaries.(eg square root, inverse matrix,ect)
 Performance Test:
• They should be designed to verify response time , execution time , throughput ,primary
& secondary memory utilization , traffic rates on data channels and communication
links.
 Stress Test:
• They are designed to overload a system in various ways.
• The purpose of stress testing are to determine the limitations of system and when the
system fails.
• They can provide valuable insights concerning the strength and weakness of a system.
 Structural Test:
• They are concerned with examining the internal processing logic of a software system.
• The goal of ST is to evaluate the specified number of paths through each routine in the
system to establish thoroughness of testing.
 Milestones
• The two major milestones during software design are the Preliminary Design Review
(PDR) and the Critical Design Review (CDR).

41 Class Notes Prepared By PDS

 • The major goal of a PDR is to demonstrate that the externally observable characteristics
and architectural structure of the product will satisfy the customer's requirements.
• CDR provides a final management decision point to build or cancel the system.
• The team conducting a CDR may or may not examine the additional level of detail
contained in the detailed design specification.

WALKTHROUGHS & INSPECTIONS

 Walkthroughs
• Walkthroughs and inspections can be used to systematically examine work product
throughout the software life cycle.
• .Requirements, design specifications, test plans, source code, principles of operation,
user's manuals, and maintenance procedures are some of the items that can be
examined in this manner.
• A walkthrough is not a project review, but is rather an in-depth examination of selected
work products by individuals who are qualified to offer expert opinions.
• A walkthrough team usually consists of a reviewer and three to five reviewers.
• They walkthrough technique can be beneficial with only one or two reviewers.
• The goal of a walkthrough is to discover and make note of problem areas. Problems are
not resolved during the walkthrough session. They are resolved by the reviewer
following the walkthrough session.
Several guidelines should be observed to gain maximum benefit from walkthroughs:
 Everyone's work should be reviewed on a scheduled basis. This approach ensures that
all work products are reviewed, provides a vehicle of communication among team
members.
• An open no defensive attitude by the project leader can establish a healthy atmosphere
for reviews.
 Emphasis should be placed on detecting errors.
• Errors should be noted for subsequent resolution by the reviewer.
 Major issues should be addressed.
• One reviewer should be designated as moderator in order to maintain a positive
atmosphere and to keep the walkthrough focused on major issues.
 Walkthrough sessions should be limited to 2 hours.
• This helps to limit the scope of material to be examined, reinforces the emphasis on
major issues, and provides incentive for active participation by the reviewers.

42 Class Notes Prepared By PDS

 Inspections
• Inspection teams consist of one to four members who are trained for their tasks. The
inspectors work from checklists of inspection items.
• An interesting aspect of inspections is the observation that all recent programmers tend
to make different kinds of characteristic errors.
• Errors found during an inspection can be cycled back to the programmers who make
them and with this feedback, programmers tend to eliminate those types of errors from
their subsequent work, thus improving quality and productivity.

Design Guidelines

• The following are some guidance that provide activities for organizing software design.
• Review the requirements specification and expand the external interfaces & report
formats developed during requirements analysis.
• Identify Functional & Data Abstraction , record them using Design Notations.
• Verify the system structure that satisfies the requirements.
• Specify algorithmic details for each procedure system using successive refinement ,
HIPO diagrams, pseudocode , Structured English and structured flow chart.
• Conduct CDR.
• Redesign as necessary.

Class Notes Prepared By Paul Davidson G -Dept of Computer Applications(U.G)-BHC,Trichy-17.

43 Class Notes Prepared By PDS