design and coding

8/12/2019 Design and Coding

1/327

Software Engineering

Computer Science & Engineering(Software Engineering)


2/327

SRS and its Specification


3/327

The fundamental problem of S/W Engg. is the

problem of scale As the scale changes to more complex and

larger s/w systems, new problems occur

This leads to redefining the priorities of the

activities that go into developing s/w

Software requirement in one such area to whichlittle importance was attached in the early daysof s/w development

More emphasis was on design & coding since itwas assumed that the developers understoodthe problem clearly when it was explained tothem

Introduction


4/327

As systems became more complex, itbecame clear that the system cant be

easily understood Hence the need for a more rigorous

requirements arose

Now for large s/w systems requirementsanalysis is perhaps the most difficultactivity

It is also very error-prone

Many s/w engineers believe that thiscritical area is the weakest!!


5/327

IEEE defines requirements as:

1. A condition of capability needed by the

user to solve a problem or achieve an

objective

2. A condition or a capability that must be

met or possessed by a system to satisfy

a contract, standard, specification or

other formally imposed document

Software Requirements


6/327

It is to be noted that in case of softwarerequirements mean that it is the capabilities thatthe system must have when it is developed

But since the system doesnt exist in any form,specifying its capabilities becomes all the morecomplicated

Regardless of how the requirements phaseproceeds, it ultimately ends with the SRS

SRS is a document that describes whattheproposed s/w will should do without describing

howthe s/w will do it The basic goal of the requirements phase is toproduce the SRS


7/327

Need for SRS The origin of most s/w is the need of a client

The s/w system itself is created by the developer Finally, the completed system is used by the end users

It is imperative that the requirements for the system thatwill satisfy the needs of the clients and the concerns of

the end users will have to be communicated to thedeveloper

But the problem is that the client usually doentunderstand s/w or the s/w development process

The developer doesnt understand the clients problemand the application area

The basic purpose of the SRS is to bridge thiscommunication gap


8/327

SRS is the medium through which the

client and the user needs are accurately

specified Hence the SRS forms the basis of s/w

development

A good SRS should satisfy all the parties This is something which is very hard to

achieve

It involves trade-offs and persuasion


9/327

Another important purpose of developing

an SRS is helping the clients understand

their own needs Developing an SRS helps a client and the

users to:

Think Interact

Discuss with others (including the requirement

analyst)to identify the requirements


10/327

Advantages of SRS

1.An SRS establishes the basis for

agreement between the client and thesupplier on what the s/w product will do

This basis of agreement is frequently

formalized into a legal contract betweenthe client and the developer

Through the SRS, the client clearlydescribes what it expects from the supplierand the developer clearly understandswhat should be the capabilities of the s/w


11/327

Without such an agreement, it is almostguaranteed that once the development is

over, the project will have an unhappyclient

This will obviously lead to unhappydevelopers

Client: Hey! Theres a bug!!

Developer: No! it is a s/w feature!!

The reality is that even with such anagreement, the client is frequently notsatisfied


12/327

2.An SRS provides a reference for

validation of the final product

The SRS helps the client determine ofthe s/w meets the requirements

Without a proper SRS:

Theres no way a client can determine if thes/w being developed is what was ordered

Theres no way a developer can convince

the client that all requirements have beenfulfilled


13/327

3.A high-quality s/w is a prerequisite to high-quality s/w

It is known that the primary forces driving a

project are: Cost Schedule

Quality

Consequently anything that has a favourableeffect on these factors is desirable

Boehm found that in some projects 54%of allthe errors were detected after coding and testingwas done

Out of these 45%of the error originated duringthe requirements and early design stages

That is, out of the total, approx. 25%errorsoccur during requirements and early design

stages


14/327


15/327

A wrong SRS will lead to an incorrectly

functioning system that will not satisfy the

client Clearly, to get a high-quality s/w with fewer

errors, a high-quality SRS is a must


16/327

A high quality SRS reduces the developmentcost

We know that the cost of fixing an errorincreases almost exponentially as timeprogresses

That is, a requirement error, if detected andremoved after the system has been developedcan cost upto 100 times more than removing itduring the requirements phase itself.

Phase Cost(person-hours)

Requirements 2Design 5

Coding 15

Testing 50

Operation & Maintenance 150


17/327

This table clearly shows that there can be

a tremendous reduction in project cost by

the reducing the errors in the SRS


18/327

It is known that the requirements frequently change

Some of the changes are inevitable due the changingneeds and perceptions

But many changes are due to the requirements not beingproperly analyzed

Not enough effort was put into validating therequirements

With a high-quality SRS, requirement changes that comedue to improper analyzed requirements should bereduced considerably

It is also a fact that frequent changes in the SRS

escalates the cost and severely disturbs the projectschedule

A well written SRS will reduce the project cost in additionto improving its chances of finishing on schedule


19/327

Hence, the quality of the SRS impacts: the customer & developer satisfaction

System validation

Quality of the final s/w

S/w development cost

All these points illustrate the importance of ahigh-quality SRS

Unfortunately it is not a common practice: due to lack of understanding of the role and the

importance of the SRS

To speed up development and cut costs byeliminating non-essential activities

Non-essential activities mostly mean any otheractivity other than coding


20/327

As a result many s/w projects in the

industry start with a poor-quality SRS

This frequently leads to cost and scheduleoverruns

This has lead to the s/w industry acquiring

a reputation of developing poor-qualityproducts


21/327

Characteristics of an SRS To properly satisfy the basic goals, an SRS

should have certain properties and shouldcontain different types of requirements

A good SRS is:1. Correct

2. Complete3. Unambiguous

4. Verifiable

5. Consistent

6. Ranked for importance and/or stability7. Modifiable

8. traceable


22/327

1. Correct: An SRS is correct if every

requirement included in the SRS

represents something required in thefinal system

2. A SRS is completeif everything the s/w

is supposed to do and the responses ofthe s/w to all classes of input data are

specified in the SRS

Correctness and completeness go hand-in-

hand

To ensure completeness, one has to detect

the absence of specifications


23/327

3. An SRS is unambiguousif and only if

every requirement stated has one and

only one interpretation Ambiguity is often due to the use of natural

languages to write an SRS

It is easy to understand Some formal specification language can

also be used to avoid ambiguities

difficulty in reading and understanding

particularly by the users and the clients


24/327

4. An SRS is verifiableif and only if everystated requirement is verifiable

A requirement is verifiable if there existssome cost-effective process that can checkwhether the final s/w meets that requirement

Unambiguity is essential for verfiability

Verification is often done through reviews It implies that the SRS is understandable, by

the developer,the client and the users

Understandability is extremely important as

one of the goals of the requirements phaseus to produce a document on which theclient, the developer and the users canagree


25/327

5. An SRS is consistentif there is no requirementthat conflicts with the another Terminologies may cause inconsistencies

There may be logical or temporal conflicts betweenrequirements

6. An SRS can be ranked for importance and/orstabilityif for each requirement the importance

and the stability of the requirement are indicated Generally, all requirements are not of equal

importance,some are: critical

Important

Desirable

Similarly some requirements are core requirementsthat are not likely to change as time passes

Others are more dependent on time


26/327

7. An SRS is modifiableif itsstructure and

style are such that any necessary change

can be made easily while preservingcompleteness and consistency

Writing an SRS is an iterative process

Even when the requirements of a system arespecified, they are later modified as the needs

of the clients change

Hence it should be easy to modify

But presence of redundancy is a major

hindrance to modifiability


27/327

8. An SRS is traceableis the origin of each

of its requirements is clear and if it

facilitates the referencing of eachrequirement in future development

Forward traceability means that each

requirement should be traceable to some

design & code elements

Backward traceability requires that it is

possible to trace design and code elements to

the requirements they support Traceability aids in verification and validation


28/327

Conclusion Of all the above characteristics, completenessis

the most important and hardest to ensure One of the most common problem in

requirements specification is when some of the

requirements of the client are not specified

This necessitates additions and modifications to

the requirements later in the development cycle

This is often expensive to incorporate

Incompleteness is a major source of

disagreement between the client and the

supplier


29/327

Structure of an SRS Document All the requirements of the system have to be included in

a document that is clear and concise For this it is necessary to organize the requirements

document as sections and subsections

There can be many ways to structure a requirements

document Many stds. and methods have been proposed for

organizing an SRS

The main advantage of standardizing the structure of the

document is that with an available std., each SRS will fita certain pattern

This will make it easier for others to understand

This is also one of the roles of any std.


30/327

Another advantage that these stds. give is thatby having the requirements in a std. Way, theyhelp ensure that the analyst does not forget

some major property The IEEE stds. recognize that different projects

may require their requirements to be organizeddifferently

That is, there is no one method that is suitable toall projects

Thus IEE provides different ways of structuringthe SRS

The first two sections of the SRS are same forall of them

The organization of the SRS as proposed in the

IEEE guide to SRS is given in the next slides


31/327

1.Introduction

1.1 Purpose

1.2 Scope1.3 Definitions, Acronyms & Abbreviations

1.4 References

1.5 Overview

2. Overall Description2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics2.4 General Characteristics

2.5 Assumptions & Dependencies


32/327

3. Specific Requirements

3.1 External Interface Requirements

3.1.1 User Characteristics3.1.2 Hardware Characteristics

3.1.3 Software Characteristics

3.1.4 Communication Interfaces

3.2 Functional Requirements3.2.1 Mode 1

3.2.1.1 Functional Requirement 1.1

..

..

3.2.1.n Functional Requirement 1.n

..

..


33/327

3.2.m Mode m

3.2.m.1 Functional Requirement m.1

..

..

3.2.m.n Functional Requirement m.n

3.3 Performance Requirements3.4 Design Constraints

3.5 Attributes

3.6 Other Requirements


34/327

Introduction Section:

Contains the purpose, scope, overview, etc.,of the requirements document

It also contains the references cited in thedocument and any definitions that are used

Overall Description:

Describes the general factors that affect theproduct and its requirements

Specific requirements are not mentioned

A general overview is presented that makethe understanding of the specificrequirements easier


35/327

Product Perspective: essentially therelationship of the product to to other productsis defined

It defines if the product is independent or a part ofa larger product and what would be the maininterfaces of the product

Product Functions: it provides a general

abstract description of the functions to beperformed by the product

Schematic diagrams showing a general view of thedifferent functions and their relationship with each

other is also useful User Characteristics: End user skill level etc.

General Constraints: Any other condition thatmay be satisfied for the product


36/327

Specific Requirements:

Describes all the details that the s/wdeveloper needs to know for designing anddeveloping the system

This is typically the largest and the mostimportant part of the document

This section may have different organizations The requirements can be organized by:

The modes of operation

User class

Object Feature

Stimulus

Functional hierarchy


37/327

External interface: specifies all the interfaces of thes/w to:-

The people

Other software

Hardware

Other systems

User interface: they specify each human interface thesystem plan to have, it includes:

Screen formats Content of the menus

Command structure

Hardware interface: the logical characteristics of eachinterface between the s/w and the h/w on which thes/w can run

Essentially any assumptions that the s/w is making about theh/w are to be listed here


38/327

S/w Interface: all other s/w that is needed for

this s/w to run is specified here along with the

interfaces

Communication Interface: specifies if the s/w

communicates with other entities in other

machines


39/327

The design process often has 2 levels:

At the 1stlevel the focus is on deciding:

Which modules are needed for the system The specifications of these modules

How these modules should be interconnected

This is called the system design or top-level design

At the 2ndlevel, the focus is on:

The internal design of the modules

How the specifications of the module can be

satisfied

This is called the detailed design or logic design


40/327

The detailed design essentially expands the

system design to contain more detailed

description of the processing logic and data

structures so that the design is sufficientlycomplete for coding.

Since the detailed design is an extension of the

system design, the system design controls themajor structural characteristics of the system

The system design has a major impact on the

testability and modifiability of the system

It also impacts the efficiency

Much of the design effort for designing s/w is

spent creating the system design


41/327

A design methodology is a systematic approach

to creating a design by applying of a set of

techniques and guidelines

These guidelines are not formalized and do not

reduce the design activity to a sequence of steps

that can be followed by the designer

The input to the design phase is thespecifications for the system to be designed

It is important that the specifications are:

Stable

Have been approved

Complete

Consistent

Unambiguous etc


42/327

The output of the top-level design phase is

the architectural design or the system

design for the s/w to be built A reasonable exit criteria for the phase

could be that the design has been verified

against the input specifications and has

been evaluated and approved for quality


43/327

Object-oriented or Function oriented

A design can be:

Object oriented Function oriented

In function-oriented design, the design consists ofModule definitions, with each module supportinga functional abstraction

In object-oriented design, the modules in thedesign represent data abstraction

In the function oriented design approach, asystem is viewed as a transformation function,transforming the inputs to the desired outputs

Since the purpose of the design phase is tospecify the components, each component is alsoviewed as a transformation function


44/327

The most commonly used function

oriented design methodology is known as

the structured design methodology The basic output of the system design

phase when a function oriented design

approach is being followed is: The definition of all the major data structures

in the system

All the major modules of the system

How the modules interact with each other

D i P i i l


45/327

Design Principles The design of a system should be:

Correct Verifiable

Complete

Traceable

Efficiency: proper use of scarce resources

Simplicity: makes the job of maintenanceeasier, faster and cost effective

These criteria are not independent andincreasing one may affect the other

Thus the design approach frequently requirestradeoffs

Its the job of the designer to achieve a balance

Mo

st

important


46/327

But for most purposes, simplicity is theprimary property

Thus the objective of the design process isto produce designs that are simple tounderstand

But creating a simple design of a large

system can be an extremely complex task It requires good engg. judgment

It is a creative activity and cant be

reduced to a series of steps, thoughguidelines can be provided


47/327

The principles used in the design

process are the same used in problem

analysis In fact, the methods are also similar

since both are concerned with

constructing models But there are some fundamental

differences

1 I th bl l i th d l i d f th bl


48/327

1. In the problem analysis the model is made for the problemdomain while in design a model is made for the solutiondomain

2. In problem analysis, the analyst has limited degrees of

freedom in selecting the models as the problem is given andmodeling has to represent it

In design, the designer has a great deal of freedom in decidingthe models, as the system that the designer is modelingdoesnt exist

In fact, the designer is creating a model for the system that willbe the basis of building the system

It simply means that in design, the system depends on themodel, while in problem analysis, the model depends on thesystem

3. The basic aim of modeling in problem domain is to

understand, while the basic aim of modeling in design is tooptimize (in most cases, simplicity and performance

It concludes that though the basic principles andtechniques look similar, the activities of analysis anddesign are very different.

P bl P titi i d Hi h


49/327

Problem Partitioning and Hierarchy

Dividing a problem into manageable small

pieces that can be solved separately is a goal ofs/w design

The reason behind this is that if the pieces of theproblem are solvable separately, the cost of

solving the entire problem is less than if theentire problem is solved

But the different pieces cant be solvedindependent of each other as they together

solve the larger problem This adds to the complexity which was not there

in there in the original problem

A th t i th t f


50/327

As the components increase, the cost ofpartitioning together with the added complexitymay become more than the savings achieved by

partitioning Thus the designer has to decide when to stoppartitioning

Partitioning helps in: Understandability

Maintainability

Modifiability

The design process should support as muchindependence as possible

But total independence is not possible Dependence between modules is one of the

reasons for high maintenance costs

P titi i ill k th t i


51/327

Proper partitioning will make the system easierto maintain and making the design easier tounderstand

Problem partitioning also aids design verification Problem partitioning, which is essential for

solving a complex problem, leads to hierarchiesin the design

That is, the design produced by using problempartitioning can be represented as a hierarchy ofcomponents

The relationship between the elements in thishierarchy can vary depending on the methodused

Ab t ti


52/327

Abstraction It is a very powerful concept that is used in all

engg. disciplines It is a tool that permits a designer to consider acomponent at an abstract level

This means that he doesnt have to worry about

the implementation details of the component An abstraction of a component describes the

external behaviour of the component withoutbothering about the internal details that produce

the behaviour This means that the abstract definition of a

component is much simpler than the componentitself

Ab t ti i ti l f bl


53/327

Abstraction is essential for problempartitioning

It is used to determine the components ofthe system

It can be used for existing components aswell

There are 2 common abstractionmechanisms for s/w systems:

Functional abstraction:a module is specified

by the function it performs Data abstraction:a module is specified by the

data object it generates


54/327

Functional abstraction:

Is the basis of partitioning in function-oriented

approaches When the problem is being partitioned, the

overall function for the system is partitioned

into smaller functions that comprise the

system

That is, the decomposition of the system is in

terms of functional modules

D t b t ti


55/327

Data abstraction:

Here data is treated as objects with somepredefined operations on them

These operations are the only operations thatcan be performed on those objects

These operations depend on the object and

the environment in which it is used From outside of an object, the internals arehidden, only the operations on the object arevisible

Data abstraction forms the basis for object-oriented design

Here each object is viewed as a set of objectsproviding some services

M d l it


56/327

Modularity

The real power of partitioning comes if a

system is partitioned into modules so thatthe modules are solvable and modifiableseparately

It is even better if the modules arecompilable separately

A system is considered to be modular:

If it consists of discreet components so that

each component can be implementedseparately

Change to one component has minimalimpact on other components

M d l it i d i bl t f th t


57/327

Modularity is a desirable property of the system

It helps in system debugging

It helps in system building

But a system cant be made modular just by

simply chopping it into a set of modules

Each module needs to support a well-defined

abstraction and a clear interface through which itcan interact with other modules

Modularity is where abstraction and partitioning

come together

For easily understandable and maintainable

systems, modularity is a basic objective

Partitioning and abstraction are the concepts to

achieve modularity


58/327

Top-down and Bottom-up Strategies

A system consists of components which may

have their own components

Thus it is a hierarchy of components

The highest level component corresponds to the

total system To design such a hierarchy, there are 2

approaches:

Top-down:starts from the highest level component ofthe hierarchy and proceeds to the lower level

Bottom-up:starts from the lowest-level component of

the hierarchy to progressively higher levels to the top-

level component

Top down approach


59/327

Top-down approach

Starts by identifying the major components

of the system, decomposing them intolower-level components and iterating untilsome desired level of detail is achieved

This often results in stepwise refinement

Starting from an abstract design, in eachstep the designed to a more concrete leveluntil a level is reached where no more

refinement is needed and the design canbe implemented directly

But this approach is suitable only:


60/327

But this approach is suitable only:

If the specifications of the system are clearly

known

The system development is from scratch

Hence, it is a reasonable approach if a

waterfall type of process model is being

used

However if it is to be built from an existing

system, a bottom-up approach is more

suitable

Bottom up Approach


61/327

Bottom-up Approach

Starts with designing the most basic

components and proceeds to higher-levelcomponents that use their lower-level

components

Starting from the very bottom, operations that

provide a layer of abstraction are implemented

The layer of operations of this layer are then

used to implement more powerful operations a

still higher layer of abstraction This is done until a stage is reached where the

operations supported by the layer are those

desired by the system


62/327

This approach is more suitable if a system

is to be built from an existing system

The components from the existing systemcan be used to make the new system

This approach is suitable if an iterative

enhancementtype of process is beingfollowed

Conclusion


63/327

Conclusion

Pure top-down and bottom-up strategies

are often not practical A common approach is to combine the two

approaches

This is done by providing a layer ofabstraction for the application domain of

interest through libraries of functions

This contains the functions of interest tothe application domain

Then the top down approach can be used to


64/327

Then the top-down approach can be used to

determine the modules in the system, assuming

that the abstract machine available for

implementing the system provides theoperations supported by the abstract layer

This is the approach used for developing

systems Almost universally these days, most

developments make use of the layer of

abstraction supported in a system consisting of

the library functions provided by the OS,programming languages and special-purpose

tools

Module Level concepts


65/327

Module Level concepts

These concepts are specific to function-orienteddesign

A module is a logically separable part of a program

It is a program unit that is discreet and identifiable withrespect to compiling and loading

It terms of programming language constructs a modulecan be:

Macro

Function

Procedure (or a subroutine)

Process

Package

In systems using functional abstraction, a module isusually a procedure of function or a collection of these

To produce modular designs some criteria


66/327

To produce modular designs, some criteria

must be used to select modules so that

the modules: support well defined abstractions

are solvable

are modifiable separately In systems using functional abstraction,

there are 2 modularization criteria which

are often used together

coupling

cohesion

Coupling


67/327

Coupling

The notion of coupling attempts to capture

how strongly different modules areinterconnected

It is also a measure of interdependence

among modules Highly coupled modules are joined by stronginterconnections

Loosely coupled modules have weak

interconnections Independent modules have no

interconnections

To solve and modify a module separately


68/327

To solve and modify a module separately,

a module should be loosely coupled with

other modules The choice of modules decides the

coupling between modules

Since the modules are created duringsystem design, the coupling between

modules is largely decided during system

design and cant be reduced during

implementation

It is an abstract concept and is not easily


69/327

It is an abstract concept and is not easily

quantifiable

But some major factors can be identified as

influencing coupling between modules

The most important among them are:

1. Type of connections between modules

2. The complexity of the interface3. The type of information flow between modules

Coupling increases with complexity and

obscurity of the interface between the modules

To keep coupling low the above factors should

be low

Interface: it is used to pass information to


70/327

Interface: it is used to pass information to

and from other modules

Coupling is reduced if only the definedentry interface of a module is used by

other modules

For e.g: passing information to and from amodules exclusively through parameters

Coupling would increase if a module is

used by other modules via an indirect

interface

For e.g: directly using the internals of a

module or using shared variables

Complexity is another factor that affects


71/327

Complexity is another factor that affects

coupling

The more complex the interface, thehigher will be the degree of coupling

For e.g: if a field of record is needed by a

procedure, often the entire record is passed,

rather than just passing that field

This increases the coupling

The interface should be as simple and

small as possible

The type of information flow along the interface


72/327

The type of information flow along the interfacealso affects coupling

There are 2 types of information that can flow

along an interface: Data Control

Passing or receiving control information meansthe action of the modules will depend on thiscontrol information

Transfer of data information means that amodule passes as input some data to anothermodule and gets some data as output

This allows a module to be treated as a simpleinput-output function that performs sometransformation on the input data to produce theoutput data

In general interfaces with only data


73/327

In general, interfaces with only data

communication result in the lowest degree of

coupling

The next higher degree of coupling is when there

is transfer of control data

Coupling is highest if the data is hybrid

Interface

Complexity

Type of

connection

Type of

communication

Low Simple

obvious

To module

by name

Data

control

High Complicated

obscure

To internal

elements

Hybrid

Cohesion


74/327

Cohesion

Another way of reducing the coupling among

modules is to strengthen the bond betweenelements of the same module

This is done by maximizing the relationship

between elements of the same module

Cohesion is a concept that tries to capture this

intra-modular behaviour

Cohesion determines how closely the elements

of a module are related to each other or howtightly bound are the internal elements of the

module to each other

it gives an idea to the designer about whether


75/327

g gthe different elements of a module belongtogether

Cohesion and coupling are related Usually, the greater the cohesion of each modulein the system, the lower the coupling betweenthe modules

There are several levels of cohesion: Coincidental

Logical

Temporal

Procedural

Communicational Sequential

Functional

Lowest

Highest

These levels do not form a linear scale


76/327

These levels do not form a linear scale

Sometimes two levels of cohesion are

applicable between elements of a module In such cases, the higher level is

considered

Coincidental: occurs when there is no


77/327

Coincidental:occurs when there is no

meaningful relationship among the

elements of a module

It occurs when a program is modularized

by chopping into pieces and creating

different modules

Mostly occurs when a module is created to

avoid duplicate code

It leads to strong interconnections between

modules

Logical: A module has a logical cohesion if


78/327

Logical:A module has a logical cohesion ifthere is some logical relationship betweenthe elements of module and the elements

perform functions that fall in the samelogical class

A module with type of cohesion often

leads to hybrid information flow whichleads to the worst form of coupling

Such modules also have clumsy or trickycode

In general, logically cohesive modulesshould be avoided, if possible

Temporal: is the same as logical cohesion


79/327

Temporal:is the same as logical cohesion

except that the elements are also related

in time and are executed together Modules that perform activities like

initialization, termination and clean-up

are usually temporally bound Since all the elements are executed

together, there is no need of passing a flag

and the code is thus simpler

Procedural: contains elements that belong


80/327

Procedural:contains elements that belongto a common procedural unit

For e.g: a loop or a sequence of decisionstatements in a module may be combinedtogether to form a separate module

Such modules occur when modular

structure is determined from some form offlowchart

Such cohesion often cuts across functional

lines Such a module may contain only a part of

a complete function or parts of severalfunctions

Communicational:occurs when a module


81/327

has elements that are related by a

reference to the same input or output data

That is, in a communicationally bound

module, the elements are together

because they operate on the same input or

output data

For e.g: a module to print a record

Sequential: When elements are together in


82/327

Sequential:When elements are together in

a module because the output of one forms

the input to the other Many possibilities exist:

Combine all in one module

Put 1st

half in one and 2nd

half in another & soon

Sequentially cohesive modules bear a

close resemblance to the problem structure

Functional: is the strongest cohesion


83/327

g

All the elements of the module are related

to performing a single function Functions do not mean mathematical

function but modules accomplishing a

single goal Function like compute square root and

sort the array are examples of

functionally cohesive modules

Conclusion


84/327

Conclusion

There is no mathematical formula to

determine the cohesion level of a module But a useful technique is to write a

sentence that describes, fully andaccurately the function or purpose of themodule

The following tests can be made:

1. If the sentence is a compound sentence, if it

contains a comma, or it has more than oneverb, the module is performing more thanone function, then it probably has sequentialor communicational cohesion

2 If the sentence contains words relating


85/327

2. If the sentence contains words relating

to time, like first, next, when, and

after the module probably hassequential or temporal cohesion

3.If the predicate of the sentence doesnt

contain a single specific object followingthe verb (such as edit all data) the

module probably has logical cohesion

4. Words like initialize and cleanupimply temporal cohesion

Modules with functional cohesion can


86/327

Modules with functional cohesion can

always be described by a simple sentence

However, if a description is a compoundsentence, it doesnt mean that the module

doesnt have functional cohesion

Functionally cohesive modules can alsobe described by a compound sentences

If a module cant be described by using a

simple sentence, the module is not likelyto have functional cohesion

Design notation and specification


87/327

Design notation and specification

While designing, a designer needs to record his

thoughts and decisions and to represent thedesign so that he can view it and play with it

For this design notations are used

Design notations are largely meant to be used

during the process of design and are used torepresent design and design notations

They are meant largely for the designer so thathe can quickly represent his decisions in a

compact manner that he can evaluate andmodify

These notations are largely graphical

Once the designer is satisfied with the design hehas produced the design is to be precisely


88/327

has produced, the design is to be preciselyspecified in the form of a document

To specify the design, specification languagesare used

Producing the design specification is the ultimateobjective of the design phase

The purpose of this design document is quite

different from the design notation Whereas a design represented using the design

notation is largely used by the designer, a designspecification has to be so precise and complete

that it can be used as a basis of furtherdevelopment by the programmers

Generally design specifications use textualstructures with the design notation helpingunderstanding

The design notation uses structure charts


89/327

e des g otat o uses st uctu e c a ts

to represent function-oriented design

Then a design language is used to specifya design

Structure Charts


90/327

Structure Charts

For a function-oriented design, the design can

be represented graphically by structure charts The structure of a program is made up of

modules of that program together with the

interconnection between the modules

Every computer program has a structure and

given a program, its structure can be determined

The structure chart of a program is a graphic

representation of its structure In a structure chart, a module is represented by

a box with the module name written in the box

An arrow from module A to module B represents


91/327

that module A invokes module B B is called the subordinateof A

A is called the super ordinateof B The arrow is labeled by the parameters received

by B as input and the parameters returned by Bas output

The direction of the flow of the input and theoutput parameters are represented by smallarrows

The parameters can be shown to be:

data (unfilled circle at the tail of a label)

Control (filled circle at the tail)


92/327

Main

read_nums sort add_n

a, n

a, n a

sum

a, n

switch

x, y x, y

The structure chart of the sort and add program


93/327

A

B C D

A

B C D

Iteration and decision representation

If module A repeatedly calls the modules


94/327

C and D then it is represented by a loopingarrow around the arrows joining the

subordinates C and D to A All the subordinate modules activated

within a common loop are enclosed in the

same looping arrow If the invocation of modules C and D in

module A depends on the outcome ofsome decision, that is represented by asmall diamond in the box for A with thearrows joining C and D coming out of thisdiamond

Modules in a system can be categorized into fewclasses


95/327

classes

There are some modules that obtain information

from their subordinates and then pass it to theirsuper ordinates

This kind of module is an input module

Similarly there are output modules

These take information from their superordinates and pass it on to their subordinates

Some modules are called transform modules

These modules transform data from one forminto another

Most of the computational modules fall underthis category

Data toData from


96/327

Input

Module

Data to

Super ordinate

Output

Module

Super ordinate

Coordinate

Module Transform

Module

xy

Composite

Module

y

x

x

y

Different types of modules

Finally, some modules manage the flow of datato and from different subordinates


97/327

to and from different subordinates

Such modules are called coordinate modules

A module can perform function of more than onetype of module

Such a module is called a composite module

For e.g: in the previous fig. the compositemodule is an input module from the point of viewof its super ordinate as it feeds data yto thesuper ordinate

Internally it is also a coordinate module since itgets data x from one subordinate and passes it

on to another subordinate which converts it intoy

Modules in actual systems are often compositemodules

Conclusion


98/327

A structure chart is a nice representationmechanism for a design that uses functionalabstraction

It shows: The modules

Their call hierarchy

The interfaces between the modules What information passes between the modules

It is a convenient and compact notation that isvery useful while creating the design

A designer can make effective use of structurecharts to represent the model he is creatingwhile he is designing


99/327

Design Document Specification


100/327

g p

Using some design rules or methodology, aconceptual design of the system can beproduced in terms of a structure chart

This is all right while the designer is designingbut inadequate when the design is to becommunicated to other programmers or

archived for future reference To avoid these problems, the design needs to

be formally specified

The design specification is then communicated

in the design document It is used as a reference for the design phase for

later activities like detailed design orimplementation

As the design document is them means bywhich the design is communicated, it should


101/327

which the design is communicated, it shouldcontain all information relevant to future phases

It should contain: Problem specification

Major data structures

Modules and their specifications

Design decisions

The requirements document specifies theproblem in the terminology of the problemdomain

Often, before starting design, the requirements

are translated into a specification of a problemmore suited for design purposes

Thus problem restatementis the 1ststep in thedesign process


102/327

Module specification is the major part of

d i ifi i


103/327

system design specification

All modules in the system should beidentified when the system design is

complete and these modules should be

specified in the document

During system design only the module

specification is obtained because the

internal details of the modules are defined

later

To specify a module, the design document


104/327

must specify:

The interface of the module (all data items,their types, whether they are for input and/or

output)

The abstract behaviourof the module (what

the module does) by specifying the modulesfunctionality or its input/output behaviour

all other modules used by the module being

specified

This information is quite useful in

maintaining and understanding the design

Hence, a design specification will necessarilycontain specification of the major data structures


105/327

p jand modules in the system

After a design is approved (using some

verification mechanism), the modules will have tobe implemented in the target language

This requires that the module headers for thetarget language first be created from the design

The translation of the design for the targetlanguage can introduce errors if its donemanually

To eliminate these errors, if the target language

is known, its better to have a designspecification language whose modulespecifications can be used directly inprogramming

This not only minimizes the translation errors thatmay occur but also reduces the effort required for


106/327

may occur but also reduces the effort required fortranslating the design to programs

This provides an added incentive to the designersthat the design document will not be thrown awayafter review but will be used directly in coding

To aid in understanding of the design, all major

design decisions made by the designers duringthe design process should be explainedthoroughly

The choices that were available and the reasons

for making a particular choice should beexplained

This makes the design more visible

Structured Design Methodology


107/327

Creating the s/w system design is a major

concern of the design phase The aim of the design methodologies is

not to reduce the process of design to asequence of steps

But it is to provide guidelines to aid thedesigner during the design process

The SDM is one of the design

methodologies for developing systemdesigns

SDM views every s/w system as havingi t th t t d i t


108/327

some inputs that are converted intodesired outputs by the s/w system

The s/w is viewed as a transformationfunction that transforms the given inputsinto the desired outputs

The central problem of designing s/wsystems is to be properly designing thistransformation function

Due to this view, the SDM is primarilyfunction oriented

Thus it relies heavily on functionalabstraction and functional decomposition

The concept of a program lies at the heart


109/327

of the SDM

During design, SDM aims to control andinfluence the structure of the final program

The aim is to design a system so that:

programs implementing the design wouldhave a hierarchical structure

Has functionally cohesive modules

As few interconnections between modules as

possible

In a properly designed system, it is often the

th t d l ith b di t d t


110/327

case that a module with subordinates does not

actually perform much computation

The bulk of actual computation is performed byits subordinates

The module itself largely coordinates the data

flow between the subordinates to get thecomputations done

The subordinates in turn get the bulk of their

work done by their subordinates until the

atomic modules which have no subordinatesare reached

Factoringis a process of decomposing a moduleso that the bulk of its work is done by its


111/327

so that the bulk of its work is done by itssubordinates

A system is said to be completely factored if allthe actual processing is accomplished bybottom-level atomic modules and if the non-atomic modules largely perform the jobs ofcontrol and coordination

SDM attempts to achieve a structure that isclose to being completely factored

The overall strategy is to identify the input andthe output streams and the primary

transformations that have to be performed toproduce the output

High-level modules are then created to performthese major activities which are later refined

There are 4 major steps in this strategy:


112/327

1. Restate the problem as a data flow diagram

2. Identify the input and output data elements3. First-level factoring

4. Factoring of input, output, and transform

branches

1.Restate the problem as a DFD


113/327

The 1ststep is to construct the DFD

DFDs can be drawn during requirement analysisand during structured design

In the requirements analysis, a DFD is drawn tomodel the problem domain

During design activity, the DFD represents howthe data will flow in the system when it is built

In this modeling, the major transform orfunctions in the software are decided

The DFD shows the major transforms that the

s/w will have and how the data will flow throughthe different transforms

DFD


114/327

Data flow diagrams (also called data flow

graphs) are useful in understanding a systemand can be effectively used in analysis anddesign

It views a system as a function that transformsthe inputs into the desired outputs

Any complex system will not perform thistransformation in a single step but data willtypically undergo a series of transformationsbefore it becomes the output

A DFD aims to capture the transformations thattake place within a system to the input data sothat eventually the output data is produced

The agent that performs the

t f ti f d t f t t t


115/327

transformation of data from one state to

another is called a process or a bubble

The processes are shown by named

circles and data flows are represented by

named arrows entering or leaving the

bubbles

A rectangle represents a source or sink

and is a originator or consumer of data

A source or a sink is typically outside the

main system of study

Sort A process


116/327

Sort A process

x,y Data flow

WorkerOriginator/ Consumer of data

*, + Multiple data flows, * = AND , * = OR

Employee RecordExternal files

Most of the systems are too large for a singleDFD to describe the data processing clearly


117/327

DFD to describe the data processing clearly

It is necessary that some decomposition and

abstraction mechanism be used for suchsystems

DFDs can be hierarchically organized whichhelps in progressively partitioning and analyzinglarge systems

Such DFDs are called leveled DFD set A leveled DFD set has a starting DFD which is a

very abstract representation of the system

It only identifies the major inputs, outputs and

the major processes in the system Then each bubble is refined and a DFD drawn

for the process i.e. a bubble in a DFD isexpanded into a DFD during refinement

For the hierarchy to be consistent, it is importantthat the net inputs and outputs of a DFD for a


118/327

that the net inputs and outputs of a DFD for aprocess are the same as the inputs and outputs

of the process in the higher level DFD This refinements stops if each bubble is

considered to be atomic i.e. each bubble canbe easily understood

It is to be noted that during refinement, thoughthe net input and output are reserved, arefinement of the data might also occur

That is, a unit of data may be broken into its

components for processing when the detailedDFD for a process is being drawn

So, as the processes are decomposed, datadecomposition also occurs

Some points to remember:

A DFD i t fl h t


119/327

A DFD is not a flowchart

A DFD represents the flow data while a flowchart

represents the flow of control

A DFD doesnt represent procedural information

While drawing a DFD, the procedural details and

thinking must be avoided For e.g: considerations of loops and decisions

must be ignored

The designer of the DFD should only specify the

major transforms in the path of the data flowingfrom the input to the output

Howthose transforms are performed is not an

issue while drawing the DFD

Following are some suggestions to draw aDFD


120/327

DFD:

Work your way consistently from the inputs tothe outputs or vice versa. If you get stuck,reverse direction

Start with a high-level data flow graph with a

few major transformations describing theentire transformation from the inputs to theoutputs and then refine each transform withmore detailed transformations

Never try to show control logic. If you findyourself thinking in terms of loops ordecisions, it is time to stop and start again

Label each arrow with proper data

elements Inputs and outputs of each


121/327

elements. Inputs and outputs of each

transform should be carefully identified

Make use of * and + operations and show

sufficient detail in the data flow graph

Try drawing alternate data flow graphs

before settling down on one

Some common errors while drawing a

DFD are:


122/327

DFD are:

Unlabeled data flows

Missing data flows: information required by a

process is not available

Extraneous data flows: some information is

not being used in the process

Consistency not maintained during refinement

Missing processes

Contains control information

Unlabeled data flows:

It is the most common error


123/327

It is the most common error

If an analyst cant label the data flow, it is likely

that he doesnt understand the purpose andstructure of that data flow

Missing data flow:

To check for this the analyst should ask:

Can the process build the outputs shownfrom the given inputs?

Extraneous data flow:

Check for redundant data flows by asking:Are all data flows required in the computationof the output?

Consistency:

Can be easily lost if new data flows are added


124/327

Can be easily lost if new data flows are added

to the DFD during modification

If such changes are made, appropriate

changes should be made in the parent or the

child DFD

If a new data flow is added in a lower-levelDFD, it should also be reflected in the higher-

level DFDs

If a data flow is added in a higher-level DFD,

the DFD for the processes affected by thechange should also be appropriately modified

Missing processes and control information:

The DFD should be carefully scrutinized to


125/327

The DFD should be carefully scrutinized to

make sure that all the processes in the

physical environment are shown in the DFD

It should also be ensured that none of the

data flows is actually carrying control

informationA data flow without any structure or

composition is a potential candidate for

control information

An example: Word counting


126/327

Problem: To determine the no. of different

words in the file

Determine the no.

of different

words

Input word file No. of words

Level 0 DFD


127/327

Get word list

Count no.

ofDifferent

words

Inputword

file

w.l.

No. of words

Level 1 DFD

Print


128/327

Get word

list

Input

wordfile

Sort thelist

w.l.

Count the

no. of differentwords

Print

the

count

Sortedw.l.

mai

count

mao

Level 2 DFD

2. Identify the most abstract input

and output data elements


129/327

and output data elements

Sometimes the transformations cant be easilyapplied to the actual physical input and producethe desired physical output

Then it becomes necessary to convert the

inputs/outputs into a form on which thetransformation can be applied with ease

The goal of this step is to separate thetransforms in the DFD that convert the

input/output to the desired format from the onesthat perform the actual transformations

For this separation, once the DFD is ready thenext step is to identify the highest abstract level


130/327

next step is to identify the highest abstract levelof input/output

The most abstract input data elements (mai)arethose that are furthest removed from thephysical inputs but can still be considered inputsto the system

MAI data elements are recognized by startingfrom the physical inputs and traveling towardsthe outputs in the DFD until the data elementsare reached that no longer be consideredincoming

The aim is to go as far as possible from thephysical inputs without losing the incomingnature of the data element

MAO:Identified by starting from the outputs inthe DFD and traveling towards the inputs


131/327

g

These are data elements that are most removed

from the actual outputs but can still beconsidered outgoing

The MAO data elements may also beconsidered the logical data items that are to be

converted into a form that is required as theoutput

There will usually be some transforms leftbetween the MAI and MAO data items

Central Transforms:performs the basictransformation for the system taking the MAI andtransforming it into the MAO

Print


132/327

Get word

list

Input

wordfile

Sort thelist

w.l.

Count the

no. of differentwords

Print

the

count

Sorte

dw.l.

mai

count

mao

DFD for word counting problem

The arcs in the DFD show the MAI and theMAO


133/327

MAO

The choice for the MAI is done as:

Start with the input

The input file is converted into a word-listwhich is essentially the input in a differentform

The sorted word-list is still basically the input,as it is still the same list in a different order

This appears to be the MAI since the next

data(i.e. the count) is not just another form ofthe input data

The MAO is chosen as:

Count is the natural choice :


134/327

Count is the natural choice :

All other data items are classified as inputs

there is only more transformation left

3. First-Level Factoring


135/327

Having identified the central transforms, the MAIand MAO, the next step is to identify somemodules for the system

First the main module is to be specified whosepurpose is to invoke the subordinates

The main module is therefore the coordinatemodule

For each of the MAI data items, an immediatesubordinate module to the main module isspecified

Each of these modules is an input module,whose purpose is to deliver to the main modulethe most abstract data item for which it iscreated

Main


136/327

Output

countGet sorted

word list

sorted w.l.count

Count no. of

different words

sorted

w.l.

cou

nt

Similarly, for each MAO data item, a subordinate

module that is an output module that accepts


137/327

p p

data from the main module is specified

Each of the arrows connecting these input andoutput subordinate modules are labeled with the

respective abstract data item flowing in the

proper direction

Finally, for each central transform, a module

subordinate to the main one is specified

These modules will be the transform modules

whose purpose is to accept data from the mainmodule and then return appropriate data back to

the main module

The data items coming to a transform modulefrom the main module are on the incoming arcsof the corresponding transform in the DFD


138/327

of the corresponding transform in the DFD

The data items returned are on the outgoingarcs of that transform

The structure after the first-level factoring of theword-counting problem is shown

In this example, there is one input module whichreturns the sorted word list to the main module

The output module takes the value of the countfrom the main module

There is one central transform in this example,and a module is drawn for that

3. Factoring the input, output andtransform branches


139/327

transform branches The first-level factoring results in a very-high

level structure, where each subordinate module

has a lot of processing to do

To simplify these modules, they must be

factored into subordinate modules that willdistribute the work of a module

Each of the input, output and transform modules

must be considered for factoring

Lets consider the input modules first:

The purpose of an input module, as viewed bythe main program, is to produce some data


140/327

To factor an input module, the transform in theDFD that produced the data item is now treatedas a central transform

The process performed for the first-levelfactoring is repeated here with this new centraltransform with the input module being

considered the main module A subordinate input module is created for each

input data stream coming into this new centraltransform

The new input modules now created can then befactored again, until the physical inputs arereached

Factoring of input modules will usually not yieldany output subordinate modules

Get sorted list

w.l. s.wl.


141/327

Get word list Sort

w.l.w.l.

s.wl.

Get a word Add to word list

Factoring the input module

The factoring of the input module get-sortedlistin the first-level structure is shown above

The transform producing the input returned by


142/327

The transform producing the input returned bythis module (i.e. the sorttransform) is treated as

a central transform Its input is the word list

Thus in the first factoring we have an inputmodule to get the list and a transform module to

sort the list The input module can be factored further, as the

module needs to perform 2 functions: Getting a word

Adding it to the list The looping arrow is used to show iteration

Factoring the output module:

The factoring of the output module is


143/327

symmetrical to the factoring of the input modules

For an output module, a search is made for thenext transform that can be applied to bring theoutput closer to the ultimate output

This now becomes the central transform, and an

output module is created for each data streamgoing on this transform

During the factoring of output modules, there willalways be no input modules

In this e.g. there is only one transform after theMAO so this factoring need not be done

If the DFD of the problem is sufficiently detailed,

factoring of the input and the output modules is


144/327

straightforward

But there are no such rules for factoring thecentral transforms

The goal is to determine sub-transforms that will

together compose the overall transform Repeat the process for the newly found

transforms, until the atomic modules is reached

Factoring the central transform is essentially an

exercise in functional decomposition and willdepend on the designers experience and

judgment

Transform module:

One way to factor a transform module is to treatit as a problem in its own right and start with a


145/327

it as a problem in its own right and start with aDFD for it

The inputs to the DFD are the data coming intothe module and the outputs are the data beingreturned by the module

Each transform in this DFD represents a sub-

transform of this transform The central transform can be factored by

creating a subordinate transform module foreach of the transforms in this DFD

The process can be repeated for the newtransform modules that are created until theatomic level is reached

The factoring of the central transform count-the-no-of-different-wordsshown below:

Count no. of

different words


146/327

Get a wordSame as

previous

Increment

count

w.l.word

word flagcount

count

Factoring the central transform

Design Heuristics The design steps mentioned earlier do not


147/327

g preduce the design process to a series of steps

that can be followed blindly The strategy requires the designer to exercise

sound judgment and commonsense

The basic objective is to make the program

structure reflect the problem as closely aspossible

The SDM should be treated as an initialstructure which may need to be modified

Hence there are some heuristics that can beused to modify the structure, if necessary

Again these are merely pointers

The designer is still the final judge of whether aparticular heuristic is useful for a particular or not

Module size is often considered to be anindication of module complexity


148/327

In some modules that are very large & may

not be implementing a single function andtherefore be broken into many moduleseach implementing a different function

On the other hand, modules that are toosmall may not require any additionalidentity and can be combined with othermodules

However, the decision to split a module orcombine different modules should not bebased on size alone

Cohesion and coupling of modules should be theprimary guiding factors

A d l h ld b lit i t t d l


149/327

A module should be split into separate module

only if the cohesion or the original module waslow

The resulting modules have a higher degree of

cohesion and the coupling between the modules

doesnt increase

Similarly, two or more modules should be

combined only if the resulting module has a

higher degree cohesion and the coupling of theresulting module is not greater than the coupling

of the sub-modules

Also, a module should usually not be splitor combined with another module if it issubordinate to many different modules


150/327

subordinate to many different modules

As a rule of the thumb, the designer shouldtake a hard look at modules that will belarger than about 100 lines of source codeor will be less than a couple of lines

Another parameter that can be consideredwhile fine-tuning the structure is the fan-inand fan-outof modules

Fan-in of a module is the no. of arrowscoming in the module

This indicates the no. of super-ordinates of

a module

Fan-out of a module is the no. of arrows going

out of that module.


151/327

It indicates the no. of subordinates of the module

A very high fan-out is not very desirable as itmeans that the module has to control and

coordinate too many modules and may therefore

be too complex

Fan-out can be reduced by creating a

subordinate and making many of the current

subordinates subordinate to the newly created

module In general the fan-out should not be increased

above 5 or 6

Whenever possible, the fan-in should bemaximized


152/327

But this should not be obtained at the cost

of increasing the coupling or decreasingthe cohesion of modules

For e.g. implementing different functions

into a single module simply to increase thefan-in is not a good idea

Fan-in can often be increased byseparating out common functions from

different modules and creating a module toimplement that function

Another important factor that should beconsidered is the correlation of the scope ofeffect and scope of control


153/327

effectand scope of control

Scope of effect of a decision( in a module) is thecollection of all the modules that contain anyprocessing that is conditional on that decision orwhose invocation is dependent on the outcomeof the decision

The scope of control of a moduleis the moduleitself and all its subordinates (not just theimmediate subordinates)

The system is usually simpler when the scope ofeffect of a decision is a subset of the scope ofcontrol of the module in which the decision islocated

Ideally the scope of effect should be limited tothe modules that are immediate subordinates ofthe module in which the decision is located


154/327

the module in which the decision is located

Violation of this rule of thumb often results inmore coupling between modules

There are some methods that a designer canuse to ensure that the scope of effect of adecision is within the scope of control of themodule

The decision can be removed from the moduleand moved-up in the structure

Alternatively, modules that are in the scope ofeffect but are not in the scope of control can bemoved down the hierarchy so that they fall withinthe scope of control

Transaction Analysis The structured design technique discussed earlier is


155/327

g qcalled transform analysis where most of the transform in

the DFD have a few inputs and a few outputs There are situations where a transform splits an input

stream into many different sub-streams with a differentsequence of transforms specified for the different sub-streams

For e.g. this is the case with systems where there aremany different sets of possible actions and the actions tobe taken depend on the input command specified

In such situations the transform analysis can be

supplemented by transaction analysis and the detailedDFD of the transform splitting the input may look like theDFD shown below


156/327

T

a

b

c

d

+

+

+

Transaction

Centre

DFD for transaction analysis

The module splitting the input is called the

transaction centre


157/327

It need not be a central transform and may

occur on either the input branch or the

output branch of the DFD of the system

Design verification and reviews

Th t t f th t d i h


158/327

The output of the system design phase

should be verified before proceeding withthe activities of the next phase

The most common approach for

verification is design reviews or inspection

Design Reviews

The purpose of the design review is to ensure


159/327

p p g

that the design satisfies the requirements and

is of good quality

If errors are made during the design process,

they will ultimately reflect themselves in the

code and the final system

As the cost of removing faults caused by

errors that occur during design phase

increases with delay in detecting the errors, itis best if design errors are detected early,

before they manifest themselves in the

system

Detecting errors in design is the aim of design

reviews


160/327

In a system design review process a group of

people get together to discuss the design withthe aim of revealing design errors or undesirable

properties

The group must include:

a member of the system design team

the detailed design team

the author of the SRS

The author responsible for maintaining the designdocument

An independent s/w quality engineer

Each member studies the design beforethe meeting


161/327

With the aid of a checklist items are

marked that the reviewer feels areincorrect or need clarification

The member asks questions and the chief

engineer tries to explain the situation Discussion ensures and during its course

design errors are revealed

It should be noted that the aim of themeeting is to uncover the design errorsand not try to fix them, fixing is done later

A sample checklist:

The use of checklist is extremely useful for


162/327

yany review

The checklist can be used by eachmember for design study and reviewmeeting

For best results, the checklist should betailored to the project at hand

This helps to uncover problem-specific

errors But a general checklist can be:

1. Is each of the functional requirementstaken into account?

2 A th l t d t t th t


163/327

2. Are there analyses to demonstrate that

performance requirements can be met?

3. Are all assumptions explicitly stated and

are they acceptable?

4. Are there any limitations or constraintson the design beyond those in the

requirements?

5. Are external specifications of eachmodule completely specified?


164/327

The analysis model

The analysis model must achieve 3


165/327

The analysis model must achieve 3

primary objectives:1. To describe what the customer requires

2. To establish a basis for the creation of a s/w

design

3. To define a set of requirements that can be

validated once the s/w is built

4. To accomplish these objectives, the analysis

model takes the form as:

ProcessSpecification

(PSPEC)

Data Object

Description


166/327

Data

Dictionary

Data flow

Diagram

(DFD)

State Transition

Diagram(STD)

Entity

Relationship

Diagram

(ERD)

Control Specification

(CSPEC)

Description

The structure of the analysis model

At the core of the model lies the data

dictionary


167/327

It is a repository that contains

descriptions of all data objects consumed

or produced by the s/w

3 different diagrams surround the core

1. The entity-relationship diagram (ERD)

2. The data flow diagram (DFD)

3. The state-transition diagram (STD)

1. The ERD

Depicts relationships between data


168/327

Depicts relationships between data

objects The ERD is the notation that is used to

conduct the data modeling activity

The attributes of each data object isnoted in the ERD can be described using

a data object diagram

2. The DFD

Serves 2 purposes:


169/327

Serves 2 purposes:

1. To provide an indication of how data aretransformed as they move through the

system

2. To depict the functions and sub-functions

that transform the data flow

A description of each function presented

in the DFD is contained in aprocess

specification (PSPEC)

3. The STD

Indicates how the system behaves as a


170/327

Indicates how the system behaves as a

consequence of external events To accomplish this, the STD represents

the various modes of behaviour (calledstates) of the system and the manner in

which transitions are made from state tostate

The STD serves as a basis for behavioral

modeling Additional aspects of the s/w is contained

in the control specification (CSPEC)

Translating the analysis model into

a software design


171/327

DataDictionary

Data flow

Diagram

(DFD)

State Transition

Diagram

(STD)

Entity

Relationship

Diagram(ERD)

ProcessSpecification

(PSPEC)

Control Specification

(CSPEC)

Data Object

Description

The analysis model

Procedural

design

Interface

design

Architectural

design

Data

design

Each of the elements of the analysismodel provides information that is requiredto create a analysis model


172/327

to create a analysis model

The flow of information during softwaredesign is shown in the previous slide

Software requirements, manifested by thedata, functional and behavioral models,feed the design step

Using one of a no. of design methods, thedesign step produces a data design, an

architectural design, an interface design,and a procedural design

Risk Management

Risk concerns future happenings


173/327

It is concerned with what might cause thesoftware project to go awry

Risk is mainly due to changes in:

Customer requirements

Development techniques

Target computers

Choices:

what methods and tools to use How many people should be involved

How much emphasis on quality is enough?

It is impossible to eliminate risk

But it can be minimized


174/327

To do this, it is important to identify all therisks that are obvious to both software

enggrs. and managers

Reactive Vs. Proactive RiskStrategies


175/327

Reactive risk strategies: react when the riskactually becomes a problem

Majority of the software project teams rely onreactive risk strategy

This strategy monitors a project for likely risks

Resources are set aside for them should theybecome actual problems

Most commonly the software team does nothingabout the risks until something goes wrong

Then the team flies into action in an attempt tocorrect the problem rapidly

This is often called the fire-fighting mode

When this fails, crises managementtakes over and the project is in real

jeopardy


176/327

j p y

A more intelligent strategy for riskmanagement is to be proactive

This strategy begins long before technicalwork is initiated.

Potential risks are identified, theirprobability and impact are assessed andthey are prioritized by importance

Then the software team establishes a planfor managing a risk

The primary objective is to avoid risk

But because not all risks can be avoided,


177/327

the team works to develop a contingency

plan that will enable it to respond in a

controlled and effective manner

Software Risks Risk involves two characteristics:


178/327

Uncertainty: The event that characterizes the

risk may or may not be happen i.e. there areno 100% probable risks

Loss: if the risk becomes a reality, unwantedconsequences or losses will occur

When risks are analyzed it is important toquantify the level of uncertainty anddegree of loss associated with each risk

To accomplish this, different categories ofrisk are considered

Project risks:threaten the project plan

That is, if the project risks become real it islikely that the project schedule will slip and


179/327

likely that the project schedule will slip and

that costs will increase Project risks identify potential:

budgetary

schedule personn

design and coding

Documents