SOFTWARE

© Copyright PCTI Group 2009 | | <document classification>

SOFTWARE

• The part of computer which have collection of computer programs, procedures, rules , associated documentation and data Which are collected for specific purpose.


Category of software

• Simple software

- A small program.

- designed, developed, used by the same person.

- no systematic approach is required.

• Industrial strength software

- use some systematic approach called programming systems.

- used by different user in different platform

- complexity is high.


SOFTWARE ENGINEERING:

• it is systematic, disciplined, quantifiable approach to the development, maintenance of the software to ensure the best solution most economically


CHARACTERISTICS OF SOFTWARE.

• 1. Software is developed - it is not manufacture.• 2. Software is highly malleable.• 3. Software does not "wear out".• 4. Most software is created from scratch and not

assembled from existing component.


SOFTWARE MYTHS

• 1 software is easy to change.• 2. Computer provide greater reliability than the

devices they replace.• 3. Testing software or 'providing software correct

can remove all the errors.• 4. Reusing software increase safety.• 5. Software with more feature is better software.


SOFTWARE PROBLEM :

• 1) EXPENSIVE:

• - software is labor intensive.

• - productivity is measured in term of DLOC (deliverable lines of code) per person-

month.

• 2) LATE

• 3) UNRELIABILITY

• 4) REWORK AND IMPLEMENTATION


REASONS OF SOFTWARE PROCESS FAIL:

• 1. Not enough time

• 2. Lack of knowledge

• 3. Wrong motivations

• 4. Insufficient commitment


QUALITIES OF SOFTWARE PRODUCT

• CORRECTNESS:

• Software which satisfies it’s functional requirement and user objective.

• More accurate the requirement specification ,more accurate the software will be.

• RELIABILITY:

• The degree to which the system performs its intended functions over time.


MAINTAINABILITYThe ease with which the program errors are detected and removed.

PORTABILITYThe ease of transporting a program from one hardware configuration to another.

TESTABILITYThe effort required to test a program to ensure its correct performance.


ROBUSTNESS :Software must accommodate any unforeseen, sudden

change in the environment .

USER FRIENDLINESSThe efforts required to understand and operate a system.

It is the measure of an effort required to configure, learn, use the software.

VERIFIABILITYA software is verifiable if it’s properties such as

performance , correctness etc. can be verified easily.


MODULARITY

• A system that is composed of modules is called modular system.

Advantage of using modular design:• decomposition• understanding


FUNDAMENTAL PROBLEM OF SOFTWARE ENGINEERING :

• THE PROBLEM OF SCALE :• Small software will not work for the large system.• To change small to large system requires formal

method of software development as well as the formal method of project management


PROBLEM of CSQ(cost,schedule,quality) :

• COST :• - The cost of developing a system is the cost of

resources . • - the cost of manpower spent on the project.

• SCHEDULE :• Business trend require that the cycle time from the

accept to delivery of a product should be small.


QUALITY :

- qualities related to the operation of the system

- qualities related to the maintenance


S/W ENGINEERING PARADIGM

• It is essentially a set of steps that comprises of methods ,tools and procedures.


COMPONENT OF SOFTWARE PROCESS

• Development process• Project management process


SOFTAWARE PROCESS

• The process that deals with the technical and management issues of software development.


TWO CATEGORIES OF PROCESS MODELS

• NON SOFTWARE ENGG. PROCESSS MODEL– BUSINESS PROCESS MODEL– SOCIAL PROCESS MODEL– TRAINING MODEL

These process also effect the software development activity but are beyond the purview of software engineering.


SOFTWARE DEVELOPMENT LIFE CYCLE

• The evolution of software development represents the cycle of activities involved in the development ,use and maintenance of software systems.

• The software life cycle are characterised into two part– - descriptive

How the software system should be developed.– - prescriptive

How software system are actually developed.


Three basic type of entities that Software engineering deals

• PROCESES

Specifies a method of developing software.• PROJECT

It is a development project in which a software process is used.

• PRODUCTS

Software product are the outcomes of a software project .


THE SYSTEM DEVELOPMENT LIFE CYCLE

• The set of activities that analysts ,designers and users carry out to develop and implement an information system


The SDLC consists of following phases

Preliminary Investigation : Finding problem or opportunity for improving an

information system or a procedure.


Analysis of system requirement

• Analysis is a detailed study of the various operation performed by a system and their relationships within and outside of the system.

• Data analysis on the available files, decision points and transaction handled by the present system.


Feasibility Study

• Evaluation of existing system whether the system is feasible economically, technically, by technique and time etc.

To decide either to go ahead with the project or to drop it.


• Feasibility study is done to find out whether fo r the system that it is proposed ,it will be :

• Possible :(to build it with the given technology and resources)

• Affordable: (given the time and cost constraint of the organization)

• Acceptable: for use by the eventual users of the system)


DIFFERENT TYPE OF FEASIBILITY • TECHNICAL FEASIBILITY.• OPERRATIONAL FEASIBILITY.• ECHONOMIVAL FEASIBILITY.• TIME FEASIBILITY.• SOCIAL FEASIBILITY.• MANAGEMENT FEASIBILITY.• LEAGAL FEASIBILITY.• TECHNICAL FEASIBILITY.


OPERATIONAL FEASIBILITY • It is mainly related to human organizational and

political aspect.• The point to be considered are ;• What changes will be brought with the system?• What new skills will be required?• What organization structures are distributed?


ECONOMIC FEASIBILITY

• The following category of cost would need to be considered.

• procurement cost – include cost of equipment purchase, cost of site preparation ,etc.

• Start-up cost : include cost of system software, communication equipment, cost of recruiting manpower.


Project costs – include actual development cost of the software, training cost, datapreparation,conversion cost.

Ongoing cost – it takes time and money to keep the system going even after it is implemented.


SOCIAL FEASIBILITY

• Social feasibility is a determination of whether a proposed project will be acceptable to the people or not.


MANAGEMENT FEASIBILITY

• It is a determination of whether a proposed project will be acceptable to management .


LEGAL FEASIBILITY

• Legal feasibility is a determination of whether a proposed project infringes ,violation, contracts or liabilities.


Design of system

• It describes a final system and process by which it is developed.

• It refers to the technical specifications that will be applied in implementing the candidate system.


TestingThe system is used experimentally to ensure that the software does not fail.

Implementation

It is the process of having system personnel check out and put new equipment into use ,train persons ,install the new application and construct any files of data needed to use it.


Post-implementation ,maintenance

and evaluation• After the system is implemented and conversion is

completed ,a review should be conducted to determine whether the system is meeting expectations and where improvements are needed .

• It review measures the system performance against pre-defined requirements.


SOFTWARE ENGG. PROCCESS MODELS

• 1 Water fall model• 2. Prototype model• 3. Iterative enhancement model• 4. The spiral model


WATER FALL MODEL :A sequence of descending step.The essence of this models is that the

process of software development consist of a set of distinct phases.

• - REQUIREMENT ANALYSIS & SPECIFICATION• - SYSTEM DESIGN• - DETAILED DEIGN• - CODING & UNIT TESTING• - INTEGRATION & SYSTEM TESTING• - OPERATION & INTEGRATION


The Linear Model

analysis design code test

System/informationengineering


LIMITATION OF WATER FALL MODEL

• This model is suitable to automate for which all requirements are known before the design starts.

• The water fall model does not accommodate times.• Water fall model is document driven.• It does not incorporate any kind of risk assessment.


PROTOTYPING MODEL

• it is well suited for projects where the requirements are hard to determine.

• it serves as a mechanism for identifying software requirements.

• it is an excellent technique for reducing risks associated with a project.


REQUIREMENT ANALYSIS

DESIGN

CODE

TEST

OPERATION AND MAINTENANCE

Refinement of requirement as per suggestion

Quick design

implement

Customer evolution


Prototype Model

listento

customerbuild/revise

mock-up

customertest-drivesmock-up

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

businessmodeling

datamodeling

processmodeling


testing&

turnover

businessmodeling

datamodeling

processmodeling


testing&

turnover

team #1

team #2team #3

60 - 90 days

Prototyping

RAD


Prototype reduce S/W Development cost

• Reduce the cost of later phases of the product development.

• The final system developed will be more closer to the actual requirement because the user and developer gets involved in refining the system.

• Requirement obtained after having the working experience with the prototype tends to be more stable.


LIMITATION OF PROTOTYPE MODEL

• * Limited functional capabilities• * low relaibility• * untested performance


ITERATIVE ENHANCEMENT MODEL• The iterative model combines the features of both

waterfall and prototype model.• it supports the increamental building of the new

system.• this model can be useful if the core of the

application is well understood and increments can be easily defined and negotiated .

• In client-oriented projects , it is an advantage to the client can pay to the projects in installments .

• the potential danger of this method is that the iteration may never end the user may never really get the "final" product .


The Incremental Model


System/informationengineering




increment 2

increment 3

increment 4

increment 1

delivery of1st increment

delivery of2nd increment

delivery of3rd increment

delivery of4th increment

calendar time


THE SPIRAL MODEL

• This model was proposed by barry boem in 1988.

• -it incorporates the elements of the prototype driven approach along with the classic software life cycle.


The four major activites of each spiral are represented by the four quadrants :

• PLANNING – determination of objectives,alternatives and constraints.

• RISK ANALYSIS – analysis of alternatives and identification/resolving of risks.

• ENGINEERING - Development of the next level product

• CUSTOMER EVALUTION - Assessment of the result of re-engineering.


p ro to ty p e 1

R isk a n a ly s isP lan n in g

C u sto m er ev a lu tio n E n g in ee rin g

p ro to ty p e 2

P ro to ty p e 3

P ro to ty p e 4

commitment

Concept of operation

software

req

Risk analysis based on customer reaction

Determine objectives alternatives ,constraint


SOFTWARE METRICS • Software metrics are objective and quantitative

data that is used to measure different characteristics of a software system or the software development process.


CATEGORY OF METRICS :

• Direct matrics– LOC (line of code)– Execution speed – defect rate – memory size

• Indirect metrics– Functionality– Efficiency– Maintainability


Software Matrics Category• Technical metrics : focus on the characteristics

such as logical complexity ,degree of modularity etc. of the software.

• Quality metrics : provide an indication of how closely software to customer requirements.

• Productivity metrics : focus on the output of the development process.


Human-oriented metrics : human perception about effectiveness of tools and methods.

Size-oriented metrics : direct measures of development process output and quality.

Function-oriented metrics : provide indirect measures.


SIZE-ORENTED METRICS• Size-oriented metrics is direct measures of

software and the process by which it is developed.

• It is programming language dependent and implementation dependent

• Easy to calculate

• It is the relation of size with the cost and quality that makes size an important metric.


Productivity = KLOC/person-month

Quality = defects / KLOC

Cost = $ / KLOC

Documentation = pages of documentation / KLOC


Function – Oriented Metrics

• Proposed by ALLAN ALBRECT of IBM in 1979• Function-oriented metrics are indirect measures

of the process by which software is developed.• Focuses on the functionality and utility.• By function point approach system functionality

is calculated in term of no. of function , the number of inputs, the number of outputs

• It is not dependent on programming language


This method of arriving at the estimates consists of the following steps

• Compute the function count (FC)– Function points are calculated based on

the following five parameters :– user inputs

• output files

– internal files– external interfaces– user inquiries


• For each of these it is determined how many are simple ,average or complex

• Once the level of complexity is established then each is multiplied by the appropriate factor

• Total weighted sum is called total unadjusted function points or function counts.


Weighting factor

Measurement Parameter count simple AverageComplex

No. of User Input * 3 4 6 =

No. of User Output * 4 5 7 =

No. of user inquiries * 3 4 6 =

No of Files * 7 10 15 =

No of External Interface * 5 7 10 =

Count Total


5 3

UFP = ∑ ∑ wij C ij

i=1 j=1

Where Cij = count of i th

row and Jth

column

Wij = weight in j th

column and i th

row


Step 3 . Compute complexity adjustment factor

• This factor is calculated by• CAF = 0.65 * 0.01 N• Where N = the sum of 14 different complexity

adjustment values• such as reusability, extensibility, performance, data

communication , transaction rate , installation ease, end user efficiency ,heavily used configuration , complex processing ,multiple sites ,distributed processing, online-update ,online-data entry


Step 4: Compute the delivered function point measure (DFP)

• DFP = CAF* UFP

Step5: Compute product and quality metrics• Productivity = DFP/person-month• Quality = defects / DFP• Cost = $ / DFP• Documentation = pages of doc. / DFP


There are several tools in structured analysis :

– Data flow diagram– Data dictionary– Structured English– Decision trees– Decision table


Dataflow diagram -> is a very important graphic tool which is used o describe and analyses the movement of data through a system manual or automated.

Data dictionary -> the data dictionary stores details and description of all data used in system . it is an organized listing of all the data element that are pertinent to the system .


Structured English -> it is a decision analysis tool which allow the analyst to list the steps in the order in which they should be taken no symbol or format are used.

Decision trees -> are presentation of decision variables that are graphics and sequential ,showing which condition to consider first ,which second and so, on.


Relate conditions and actions through decision rules . A decisions rule states the condition that must be satisfied for a particular set of action to be taken. The decision rule incorporate all the conditions that must be true at one time, not just one condition.

Decision tables :


DATA FLOW DIAGARAM (DFD)

• DFD ‘S ARE OF TWO TYPES :

• Physical DFD -> The physical DFD is a model of the current system and is used to ensure that the current system has been clearly understood. Physical DFD show actual devices, department, people etc involved in the current system.

• Logical DFD -> are the model of proposed system . They should clearly show the requirement on which the new system should be built.


DFD has two alternative symbol sets

• Yourdon Symbol set

• Gane – Sarson symbol set (e.g : open box)


Notation ‘s of a DFD • DATA FLOW (arrow)• PROCESS (circle)• EXTERNAL ENTITIES (Square box)• DATA STORE (Open box )


DATA FLOW ->

• Passage of data in the system in a specific direction that is from origin to destination. The direction of the flow is indicated by a arrow and the line is labeled by the name of the data

• ---------------------------------------------------------


PROCESS ->

• Process transform inputs into outputs. They are work or action that are performed by people, machine or computer on incoming data flow to produce outgoing.

PROCESS


EXTERNAL ENTITY ->

• EXTERNAL ENTITES are organization ,department or people which represent a source or destination of transaction or data.

• Entity that supplies or receives information from the system but is not a part of the system


DATA STORE

• It is as the memory of the system .Any place that accumulate the data is a data store. The data in a data store must have at least one data flow pointing towards it or away from it . It can be file or device.


Payroll monitoring

system

New employee

Sales dept

Account dept

Admin dept

employee

Account dept

Sales dept

bank

CONTEXT DIAGRAM


Software Requirement Specification.(SRS)

This document is generated as output of requirement analysis. The requirement analysis involves obtaining a clear and thorough understanding of the product to be developed. Thus SRS should be…..


Characteristics of SRS

• Correctness

• Completeness

• Unambiguous

• Traceable

• Verifiable

• Consistent

• Modifiable


Component of SRS

The developer of the system prepare the SRS after detailed communication with the customer. An SRS clearly defines the following:

• Functional & Non-Functional Requirements of the system.

• Performance Requirements• Design Constraints• External Interface of the system: They identify the

information which is to flow ‘from and to’ the system.


SRS Common Problems

• Ambiguity

• Inconsistency

• Incorrect fact

• Omission


DATA DICTIONARY• Use to manage the details• Communicate meaning : it assists in ensuring common

meaning for system element and activities.• Document system feature : produce more complete

understanding• Facilitate Analysis : it determine whether new feature are

needed in a system or not.• Locate error and omission


The dictionary contain three types of description

• Data elements• Data structure• Data flow and Data stores

Data element

Data structure

Data flow Data store


• Data element : It is the smallest unit which has meaning. It describe data level

• Data structures : It is a set of data element that relate to one another .

• Data flow and data stores : data flow are data structure in motion whereas data stores are data structure at rest.


MAJOR SYMBOL

• Equivalent to ‘=‘• and ‘+’• either/or ‘[ ]’• optional entry ‘()’• comment ‘**’

• X=[a / b] x consist of either data element a or b.

• X = a x consist of data element a• X = a + b x consist of data element a & b


Four rules of data dictionary entry

• Word should be define to stand for what they mean.

• Each word must be unique.• Aliases or synonyms are allowed when two or more

entries show the same meaning.• Self define word should not be decomposed,


SOFTWARE DESIGN

Software design is the process of applying various software engineering techniques to develop models to define a software system, which provides sufficient details for actual realisation of the software.

Design phase of software development deals with transforming the customer’s requirements into a logically working system.


User

requirements System design Code

Information model

Functional model

Requirements

Data design

Procedural design


The Following are some of the fundamentals of design:

• The design should follow a hierarchical organization.

•Design should be modular which are logically partitioned into modules which are relatively independent and perform independent task.

•Design leading to interface that facilitate interaction with external environment.


• Step wise refinement to more detailed design which provides necessary details for the developer of code.

• Modularity is encouraged to facilitate parallel development, but, at the same time, too many modules lead to the increase of effort involved in integrating the modules.


Data design

Architectural design

Modular design

Computer Interface design

Technical aspects of design


Data Design

Data design is the first and the foremost activity of system Design.

Data describes a real-world information resource that is important for the application.

Data describes various entities like customer, people, asset, student record etc.


The primary objective of the data design is to select logical representation of data items identified in requirement analysis phase.


Architectural Design

The objective of architectural design is to develop a model of software architecture which gives an overall organisation of program module in the software product.

Architectural design defines organisation of program components. It does not provide the details of each components and its implementation.


Financial Accounting Management System

Accounts Receivable System

Fixed Asset Management System

Sundry Debtors

Architecture of a financial accounting system


The Objective of architectural design is also to control relationship between modules.

One module may control another module or may be controlled by another module.

These characteristics are defined by the fan-in and fan-out of a particular module.


The organization of module can be represented through a tree like structure.

The number of components which controls a said component is called fan-in i.e. the number of incoming edges to a component.

The number of components that are controlled by the module is called fan-out i.e. the number of outgoing edges.


So

S1 S2

S2

S1 S3

S3

Fan-in and Fan-out

So controls three components, hence the fan-out is 3. S2 is controlled by two components, namely, S1 and S2, hence the fan-in is 2.


MODULAR DESIGN

The concept of modular approach has been derived from the fundamental concept of “divide and conquer”.

Modularity is the only attribute of a software product that makes it manageable and maintainable.


Dividing the software to modules helps software developer to work on independent modules that can be later integrated to build the final product.

It encourages parallel development efforts thus saving time and cost.


There should be a balance between number of modules and integration cost. Although, more numbers of modules make the software product more manageable and maintainable at the same time, as the number of modules increases, the cost of integrating the modules also increases.


While modularity is good for software quality, independence between various modules are even batter for software quality and manageability, independence is measured by two parameters

1. Cohesion and

2. Coupling


Cohesion is a measure of functional strength of a software module. This is the degree of interaction between statement in a module.

Highly cohesive system requires little interaction with external module.

Cohesion


There are several types of cohesion arranged from bat to best.

Coincidental : This is worst form of cohesion, where a module performs a number of unrelated task.

Logical : modules perform series of action, but are selected by a calling module.


Procedural : Modules perform a series of steps. The elements in the module must takeup single control sequence and must be executed in a specific order.

Communicational : All elements in the module is executed on the same data set and produce same output data set.


Sequential: Output from one element is input to some other element in module. Such modules operates on some data structure.

Functional: Modules contain elements that perform exactly one function.


Coupling

Coupling is defined as degree to which a module interacts and communicates with another module to perform certain task.

If one module relies on another the coupling is said to be high.

Low level of coupling means a module does not have to concerned with the internal details of another module.


Types of Coupling

(From best (lowest level of coupling) to worst (high level of coupling )

Data Coupling: Modules interact through parameters. Module X passes parameter A to Module Y.

Stamp coupling: Modules shares composite data structure.


Control coupling: One module control logic flow of another module. For exp, passing a flag to another module which determines the sequence of action to be performed in the other module depending on the value of flag such as true or false.


External coupling: Modules shares external data format. Mostly used in communication protocols and device interfaces.

Content coupling: One module modifies the data of another module.


Disadvantages of Coupling

Difficult to reuse. Dependent modules must be included.

Difficult to understand the function of a module in isolation.


INTERFACE DESIGN

Interface design is the most important part of software design. The following are the elements of good interface design.

• Goal and the intention of task must be identified.

• Use of consistent color scheme, message and terminologies helps.

•


•Develop standards for good interface design and stick to it.• Use icons where ever possible to provide appropriate message.•Allow user to undo the current command.•Provide sensitive help to guide the user.•Provide Key-board short cut.


What is Testing?

• “Testing is an activity in which a system or component is executed under specified conditions; the results are observed and recorded and an evaluation is made of some aspect of the system or component

• “ - IEEE


Approaches to Testing• Debugging-oriented: • This approach identifies the errors during

debugging the program. There is no difference between testing and debugging.

• Demonstration-oriented: • The purpose of testing is to show that the

software works• . Here most of the time, the software is

demonstrated in a normal sequence/flow. All the branches may not be tested. This approach is mainly to satisfy the customer and no value added to the program.


• Destruction-oriented: • The purpose of testing is to show the software

doesn’t work.• It is a sadistic process, which explains why most

people find it difficult. It is difficult to design test cases to test the program.

• Evaluation-oriented:• The purpose of testing is to reduce the perceived

risk of not working up to an acceptable value. • Prevention-oriented:• It can be viewed as testing is a mental discipline that

results in low risk software• . It is always better to forecast the possible errors

and rectify it earlier.


Hurdles in Testing

• Usually late activity in the project life cycle• No “concrete” output and therefore difficult to

measure the value addition• Lack of historical data• Recognition of importance is relatively less• Politically damaging as you are challenging the

developer• Delivery commitments• Too much optimistic that the software always

works correctly


Testing Fundamentals

• Testing Objectives

• Testing is a process of executing a program with the intent of finding an error.

• A good test is one that has a high probability of finding an as yet undiscovered error.

• A successful test is one that uncovers an as yet undiscovered error.


Test Case Design

• Some of the points to be noted during the test case design are:

• Can be as difficult as the initial design.• Can test if a component conforms to

specification - Black Box Testing.• Can test if a component conforms to design -

White box testing.• Testing cannot prove correctness as not all

execution paths can be tested.


Questions:What is software testing? Explain the purpose of testing?

Explain the origin of the defect distribution in a typical software development life cycle?


Levels of tests

• Unit testing : in unit testing the analyst test the program making up a system. it gives stress on the module independently of one another.

• Sequential testing : is checking the logic one or more program in the candidate system . Where the output of one program affect the processing of another program.

• Positive testing : is executing a program to check logic change made in it and with the intention of finding errors – making the program fail.


• Acceptance testing : making sure that the new program do in fact process certain transaction according to specification.

• System testing : is running the system with live data by the actual user.


Six special system tests

• Peak load test : it determine whether the system will handle the volume of activities that occur when the system is at the peak of its processing demand

• Storage testing: it determine the capacity of the system to store transaction data on a disk or in other files

• Performance testing : it determine the length of time system used by the system to process transaction data.


• Recovery testing : determine the ability of the user to recover data or re-start system after failure.

• Procedure testing :clarity of documentation on operation and use of system by having users do exactly what manuals request.

• Human factor testing : it determine how users will use the system when processing data or preparing reports.


System testing consist of the following steps

• Program testing• String testing• System testing• System documentation• User acceptance testing


White Box Testing

• White box testing helps to derive test cases to ensure:

• All independent paths are exercised at least once.

• All logical decisions are exercised for both true and false paths.

• All loops are executed at their boundaries and within operational bounds.

• All internal data structures are exercised to ensure validity


White box testing helps to:Traverse complicated loop structures

Cover common data areas,Cover control structures and sub-routines,

Evaluate different execution pathsTest the module and integration of many

modulesDiscover logical errors, if any.Helps to understand the code


Basis Path Testing Flow Graph Notation

Notations used for control structures


• On a flow graph:

• Arrows called edges represent flow of control

• Circles called nodes represent one or more actions.

• Areas bounded by edges and nodes called regions.


Control flow of a program and the corresponding flow diagram


Cyclomatic Complexity• The cyclomatic complexity gives a

quantitative measure of the logical complexity. This value gives the number of independent paths in the basis set, and an upper bound for the number of tests to ensure that each statement is executed at least once.


• Cyclomatic Complexity of 4 can be calculated as: – Number of regions of flow graph, which is 4.– #Edges - #Nodes + 2, which is 11-9+2=4.– #Predicate Nodes + 1, which is 3+1=4.

• The above complexity provides the upper bound on the number of tests cases to be generated or independent execution paths in the program. The independent paths(4 paths)


• Independent Paths: – 1, 8 – 1, 2, 3, 7b, 1, 8 – 1, 2, 4, 5, 7a, 7b, 1, 8 – 1, 2, 4, 6, 7a, 7b, 1, 8

• Cyclomatic complexity provides upper bound for number of tests required to guarantee the coverage of all program statements.


Graph Matrices

• The graph matrix:

• Is a square matrix with number of sides equal to number of nodes.

• Rows and columns of the matrix correspond to the number of nodes in the flow graph.

• Entries correspond to the edges.


: Example of a graph matrix


Black Box Testing • Equivalence Partitioning • this method is to partitioning the input so that an

optimal input data is selected.• Equivalence classes can be defined by:• If an input condition specifies a range or a

specific value, one valid and two invalid equivalence classes defined.

• If an input condition specifies a boolean or a member of a set, one valid and one invalid equivalence classes defined.


Boundary Value Analysis.

• It is observed that boundary points for any inputs are not tested properly. This leads to many errors. Large number of errors tend to occur at boundaries of the input domain.

• Boundary Value Analysis(BVA) leads to selection of test cases that exercise boundary values.

• BVA complements equivalence partitioning i.e. select any element in an equivalence class, select those at the ''edge' of the class.


Cause Effect Graphing Techniques.


C 1 V

V

V V

V

VV

E 1

C 2

E 2

C 3

E3

C 4

E 5

E 4


Representation of cause-effect nodes

SNo. 1 2 3 4 5cl 0 1 x x 1 c2 0 x 1 1 xc3 x 0 1 1 1 c4 x x 0 1 1el 1e2 1e3 1e4 1e5 1

Decision Table for the Cause-effect Graph


Comparison Testing

• Test each version with same test data to ensure all provisional identical output.

• Run all versions in parallel with a real-time comparison of results.

• Even if will only run one version in final system, for some critical applications can develop independent versions and use comparison testing or back-to-back testing.


Level of quality assurance

• Testing

• Verification with validation

• Certification


VERIFICATION AND VALIDATION

• Verification refers to the set of activities that ensure that correctly implements a specific function.

• Validation refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.

• Boehm states like this.• Verification: "Are we building the product right"• Validation: "Are we building the right product?"


Quality

SoftwareEngineering

Methods

FormalTechnicalReview

StandardsAnd

ProceduresSCM

&SQA

Testing

Measurement

Figure 5.1. Achieving Software Quality


S

R

D

CU

IV

ST

System Engineering

Requirements

Design

CodeUnit Test

Integration testValidation Test

System test


Error

• It is the discrepancy between a computed, observed, or measured value and true, specified, or theoretically correct value.


Fault

• It is a condition that causes a system to fail in performing its required function.

• It is synonymous with the term bug.


Failure

• It is the inability of a system or component to perform a required function according to its specifications.

• However, the presence of fault does not guarentee a failure.


J-M Model

It falls under two major categories –

• Time between failure models (MTBF).

• Fault count models (faults or time normalized rates).


J-M Model (contd…)

The following assumptions are made in this model :

• N software failures present at start of testing• Testing failures occur randomly• All faults contribute equally to cause a testing

failure.• Fix times are negligible• All fixes are perfect

• Hazard function z(ti) = [ N – (I – 1) ]


Markov Model

• The Markov property states: given the current state of the system of the system, the future evolution of the system is independent of its history.


Musa Model

• This model is based on an execution time model, i.e. the time taken during modelling is the actual CPU execution time of the software being modelled.

• Failure intensity –

() = 0 (1- / v0 )


Halstead’s Complexity Metrics

• n1 is the number of distinct operators.• n2 is the number of distinct operands.• f1j is the number of occurrences of the jth

most frequent operators.• f2j is the number of occurrences of the jth

most frequent operands.


The vocabulary

The vocabulary n of a program is defined as –

n = n1 + n2


Measurable parameters

• The total occurrences of different operators in the program –

N1 = sum f1.j

• The total occurrences of different operators in the program –

N2 = sum f2.j


The length

• The length of a program is defined as –

N = N1 + N2


The volume

• The volume of a program is defined as –

V = N log2 (n)


The ease of reading and writing of a program is –

D = (n1 * N2) / (2 * n2)


System maintenance

• Corrective

• Adaptive

• perfective


Parameter to measure software quality

• Usability

• Integrity

• Correctness

• Maintainability


Difference between flow chart and DFD

• flow chat should include control element a good DFD should not.

• have no data flows that split up into a number of other data flow

• have no crossing lines• not include flow chart loops of control

elements• not include data flow that act as

signals to activate process


PROJECT MANAGEMENT

• The process of directing the development of an acceptable system at a minimum cost within a specified time frame.

• Software project management is a very vast area and covers the management functions of planning,controlling , analysis , organizing,staffing , leading .


• PLANNING – predetermining the course of action for the project to be able to achive the specified objective

• ORGANIZING :-itemizing the project activities and then grouping these activities logically .

• STAFFING – Selecting appropriate personnel required to do the tasks as per the plan.

• LEADING – creating an atmosphere that will assist and motivate people to about their assigned tasks in the best manner possible.

• CONTROLLING – ensuring that the project goes as per plan by measuring and correcting the performance of activities.


risk analysis

• risks identification• risks assessment• risk prioritization• risk management• risk resolution• risk monitoring• Termination analysis

It is provide some information about the development process. For prediction and estimations about future projects


Method of requirement validation

• Requirement reviews

• Reading

• Scenarios

• Prototypes

SOFTWARE

Documents

Transcript of SOFTWARE