Software Engineering & Testing Course Code: 18CST54

Software Engineering & Testing Course Code: 18CST54

Course Teachers:

Mr. Vivek Sharma S1

12/11/2020NCET , DEPT. of CSE


2

An Introduction to SoftwareEngineering


3 Objectives

• To introduce software engineering and to explain its importance

• To set out the answers to key questions about software engineering

• To introduce ethical and professional issues and to explain why they are of concern to software engineers


4 Topics covered

• FAQs about software engineering• Professional and ethical responsibility


5 Software engineering

• The economies of ALL developed nations are dependent on software.

• More and more systems are software controlled• Software engineering is concerned with theories,

methods and tools for professional software development.

• Expenditure on software represents a significant fraction of GNP in all developed countries.


6 Software costs

• Software costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost.

• Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs.

• Software engineering is concerned with cost effective software development.


7 FAQs about software engineering• What is software?• What is software engineering?• What is the difference between software

engineering and computer science?• What is the difference between software

engineering and system engineering?• What is a software process?• What is a software process model?


8FAQs about software engineering• What are the costs of software engineering?• What are software engineering methods?• What is CASE (Computer Aided Software

Engineering)• What are the attributes of good software?• What are the key challenges facing software

engineering?


9 What is software?

• Computer programs and associated documentation such as requirements, design models and user manuals.

• Software products may be developed for a particular customer or may be developed for a general market.

• Software products may be• Generic developed to be sold to a range of different customers

e.g. PC software such as Excel or Word.• Bespoke (custom) developed for a single customer according

to their specification.• New software can be created by developing new

programs, configuring generic software systems or reusing existing software.


10 What is software engineering?

• Software engineering is an engineering discipline that is concerned with all aspects of software production.

• Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available.


11What is the difference between

software engineering and computer science?

• Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

• Computer science theories are still insufficient to act as a complete underpinning for software engineering (unlike e.g. physics and electrical engineering).


12What is the difference between software engineering and system engineering?

• System engineering is concerned with all aspects of computer based systems development including hardware, software and process engineering. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system.

• System engineers are involved in system specification, architectural design, integration and deployment.


13 What is a software process?

• A set of activities whose goal is the development or evolution of software.

• Generic activities in all software processes are:• Specification what the system should do and its

development constraints• Development production of the software system• Validation checking that the software is what the

customer wants• Evolution changing the software in response to

changing demands.


14 What is a software process model?

• A simplified representation of a software process, presented from a specific perspective.

• Examples of process perspectives are• Workflow perspective sequence of activities;• Data flow perspective information flow;• Role/action perspective who does what.

• Generic process models• Waterfall;• Iterative development;• Component based software engineering.


15 What are the costs of software engineering?

• Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.

• Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability.

• Distribution of costs depends on the development model that is used.


16Activity cost distribution


17 Product development costs


18 What are software engineering methods?

• Structured approaches to software development which include system models, notations, rules, design advice and process guidance.

• Model descriptions• Descriptions of graphical models which should be produced;

• Rules• Constraints applied to system models;

• Recommendations• Advice on good design practice;

• Process guidance• What activities to follow.


19 What is CASE (Computer Aided Software Engineering)

• Software systems that are intended to provide automated support for software process activities.

• CASE systems are often used for method support.• Upper CASE

• Tools to support the early process activities of requirements and design;

• Lower CASE• Tools to support later activities such as programming,

debugging and testing.


20 What are the attributes of good software?

• The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable.

• Maintainability• Software must evolve to meet changing needs;

• Dependability• Software must be trustworthy;

• Efficiency• Software should not make wasteful use of system resources;

• Acceptability• Software must accepted by the users for which it was designed.

This means it must be understandable, usable and compatible with other systems.


21 What are the key challenges facing software engineering?

• Heterogeneity, delivery and trust.• Heterogeneity

• Developing techniques for building software that can cope with heterogeneous platforms and execution environments;

• Delivery• Developing techniques that lead to faster delivery of software;

• Trust• Developing techniques that demonstrate that software can

be trusted by its users.


22Professional and ethical responsibility

• Software engineering involves wider responsibilities than simply the application of technical skills.

• Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals.

• Ethical behaviour is more than simply upholding the law.


23 Issues of professional responsibility

• Confidentiality• Engineers should normally respect the confidentiality

of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.

• Competence• Engineers should not misrepresent their level of

competence. They should not knowingly accept work which is outwith their competence.


24

Issues of professional responsibility

• Intellectual property rights• Engineers should be aware of local laws governing the use of

intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected.

• Computer misuse• Software engineers should not use their technical skills to

misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).


25 ACM/IEEE Code of Ethics

• The professional societies in the US have cooperated to produce a code of ethical practice.

• Members of these organisations sign up to the code of practice when they join.

• The Code contains eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession.


26 Code of ethics preamble

• Preamble• The short version of the code summarizes aspirations at a high

level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

• Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:


27 Code of ethics principles

• PUBLIC• Software engineers shall act consistently with the public

interest.

• CLIENT AND EMPLOYER• Software engineers shall act in a manner that is in the best

interests of their client and employer consistent with the public interest.

• PRODUCT• Software engineers shall ensure that their products and related

modifications meet the highest professional standards possible.



• JUDGMENT• Software engineers shall maintain integrity and independence

in their professional judgment.

• MANAGEMENT• Software engineering managers and leaders shall subscribe to

and promote an ethical approach to the management of software development and maintenance.

• PROFESSION• Software engineers shall advance the integrity and reputation of

the profession consistent with the public interest.



• COLLEAGUES• Software engineers shall be fair to and supportive of

their colleagues.• SELF

• Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.


30 Ethical dilemmas

• Disagreement in principle with the policies of senior management.

• Your employer acts in an unethical way and releases a safety critical system without finishing the testing of the system.

• Participation in the development of military weapons systems or nuclear systems.


31 Key points

• Software engineering is an engineering discipline that is concerned with all aspects of software production.

• Software products consist of developed programs and associated documentation. Essential product attributes are maintainability, dependability, efficiency and usability.

• The software process consists of activities that are involved in developing software products. Basic activities are software specification, development, validation and evolution.

• Methods are organised ways of producing software. They include suggestions for the process to be followed, the notations to be used, rules governing the system descriptions which are produced and design guidelines.


32 Key points

• CASE tools are software systems which are designed to support routine activities in the software process such as editing design diagrams, checking diagram consistency and keeping track of program tests which have been run.

• Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues.

• Professional societies publish codes of conduct which set out the standards of behaviour expected of their members.


33

Socio-technical Systems


34Objectives

To explain what a socio-technical system is and the distinction between this and a computer-based systemTo introduce the concept of emergent system properties such as reliability and securityTo explain system engineering and system procurement processesTo explain why the organisational context of a system affects its design and useTo discuss legacy systems and why these are critical to many businesses


35 Topics covered

Emergent system propertiesSystems engineeringOrganizations, people and computer systems Legacy systems


36 What is a system?

A purposeful collection of inter-related components working together to achieve some common objective. A system may include software, mechanical, electrical and electronic hardware and be operated by people.System components are dependent on other system componentsThe properties and behaviour of system components are inextricably inter-mingled


37 System categories

Technical computer-based systemsSystems that include hardware and software but where the operators and operational processes are not normally considered to be part of the system. The system is not self-aware.

Socio-technical systemsSystems that include technical systems but also operational processes and people who use and interact with the technical system. Socio-technical systems are governed by organisational policies and rules.


38 Socio-technical system characteristics

Emergent propertiesProperties of the system of a whole that depend on the system components and their relationships.

Non-deterministicThey do not always produce the same output when presented with the same input because the systems’s behaviour is partially dependent on human operators.

Complex relationships with organisational objectivesThe extent to which the system supports organisational objectives does not just depend on the system itself.


39 Emergent properties

Properties of the system as a whole rather than properties that can be derived from the properties of components of a systemEmergent properties are a consequence of the relationships between system componentsThey can therefore only be assessed and measured once the components have been integrated into a system


40 Examples of emergent properties


41 Types of emergent property

Functional properties These appear when all the parts of a system work together to achieve some objective. For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components.

Non-functional emergent propertiesExamples are reliability, performance, safety, and security. These relate to the behaviour of the system in its operational environment. They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.


42

Because of component inter-dependencies, faults can be propagated through the system.System failures often occur because of unforeseen inter-relationships between components.It is probably impossible to anticipate all possible component relationships.Software reliability measures may give a false picture of the system reliability.

System reliability engineering


43

Hardware reliability What is the probability of a hardware component failing and how long does it take to repair that component?

Software reliability

How likely is it that a software component will produce an incorrect output. Software failure is usually distinct from hardware failure in that software does not wear out.

Operator reliability

How likely is it that the operator of a system will make an error?

Influences on reliability


44 Reliability relationships

Hardware failure can generate spurious signals that are outside the range of inputs expected by the software.Software errors can cause alarms to be activated which cause operator stress and lead to operator errors.The environment in which a system is installed can affect its reliability.


45 The ‘shall-not’ properties

Properties such as performance and reliability can be measured.However, some properties are properties that the system should not exhibit

Safety - the system should not behave in an unsafe way;Security - the system should not permit unauthorised use.

Measuring or assessing these properties is very hard.


46 Systems engineering

Specifying, designing, implementing, validating, deploying and maintaining socio-technical systems.Concerned with the services provided by the system, constraints on its construction and operation and the ways in which it is used.


47 The system engineering process

Usually follows a ‘waterfall’ model because of the need for parallel development of different parts of the system

Little scope for iteration between phases because hardware changes are very expensive. Software may have to compensate for hardware problems.

Inevitably involves engineers from different disciplines who must work together

Much scope for misunderstanding here. Different disciplines use a different vocabulary and much negotiation is required. Engineers may have personal agendas to fulfil.


48The systems engineering process


49 Inter-disciplinary involvement

System requirements definition

Three types of requirement defined at this stageAbstract functional requirements. System functions are defined in an abstract way;System properties. Non-functional requirements for the system in general are defined;Undesirable characteristics. Unacceptable system behaviour is specified.

Should also define overall organisational objectives for the system.


50

System objectivesShould define why a system is being procured for a particular environment.Functional objectives

To provide a fire and intruder alarm system for the building which will provide internal and external warning of fire or unauthorized intrusion.

Organisational objectivesTo ensure that the normal functioning of work carried out in the building is not seriously disrupted by events such as fire and unauthorized intrusion.


51

System requirements problems

Complex systems are usually developed to address wicked problemsProblems that are not fully understood;

Changing as the system is being specified.

Must anticipate hardware/communications developments over the lifetime of the system.

Hard to define non-functional requirements (particularly) without knowing the component structure of the system.


52

The system design process

Partition requirementsOrganise requirements into related groups.

Identify sub-systemsIdentify a set of sub-systems which collectively can meet the system requirements.

Assign requirements to sub-systemsCauses particular problems when COTS are integrated.

Specify sub-system functionality.Define sub-system interfaces

Critical activity for parallel sub-system development.


53

The system design process


54

System design problems

Requirements partitioning to hardware, software and human components may involve a lot of negotiation.

Difficult design problems are often assumed to be readily solved using software.

Hardware platforms may be inappropriate for software requirements so software must compensate for this.


55

Requirements and design

Requirements engineering and system design are inextricably linked.Constraints posed by the system’s environment and other systems limit design choices so the actual design to be used may be a requirement.Initial design may be necessary to structure the requirements.As you do design, you learn more about the requirements.


56

Spiral model of requirements/design


57

System modelling

An architectural model presents an abstract view of the sub-systems making up a system

May include major information flows between sub-systems

Usually presented as a block diagram

May identify different types of functional component in the model


58

Burglar alarm system


59

Sub-system description


60

ATC system architecture


61

Sub-system development

Typically parallel projects developing the hardware, software and communications.May involve some COTS (Commercial Off-the-Shelf) systems procurement.Lack of communication across implementation teams.Bureaucratic and slow mechanism for proposing system changes means that the development schedule may be extended because of the need for rework.


62

System integration

The process of putting hardware, software and people together to make a system.

Should be tackled incrementally so that sub-systems are integrated one at a time.

Interface problems between sub-systems are usually found at this stage.

May be problems with uncoordinated deliveries of system components.


63

System installation

After completion, the system has to be installed in the customer’s environment

Environmental assumptions may be incorrect;May be human resistance to the introduction of a new system;System may have to coexist with alternative systems for some time;May be physical installation problems (e.g. cabling problems);Operator training has to be identified.


64

System evolution

Large systems have a long lifetime. They must evolve to meet changing requirements.Evolution is inherently costly

Changes must be analysed from a technical and business perspective;Sub-systems interact so unanticipated problems can arise;There is rarely a rationale for original design decisions;System structure is corrupted as changes are made to it.

Existing systems which must be maintained are sometimes called legacy systems.


65

System decommissioning

Taking the system out of service after its useful lifetime.

May require removal of materials (e.g. dangerous chemicals) which pollute the environment

Should be planned for in the system design by encapsulation.

May require data to be restructured and converted to be used in some other system.


66

Organisations/people/systems

Socio-technical systems are organisational systems intended to help deliver some organisational or business goal.

If you do not understand the organisational environment where a system is used, the system is less likely to meet the real needs of the business and its users.


67

Human and organisational factors

Process changes Does the system require changes to the work processes in the environment?

Job changes

Does the system de-skill the users in an environment or cause them to change the way they work?

Organisational changes

Does the system change the political power structure in an organisation?


68

Organisational processes

The processes of systems engineering overlap and interact with organisational procurement processes.Operational processes are the processes involved in using the system for its intended purpose. For new systems, these have to be defined as part of the system design.Operational processes should be designed to be flexible and should not force operations to be done in a particular way. It is important that human operators can use their initiative if problems arise.


69

Procurement/development processes


70

System procurement

Acquiring a system for an organization to meet some needSome system specification and architectural design is usually necessary before procurement

You need a specification to let a contract for system developmentThe specification may allow you to buy a commercial off-the-shelf (COTS) system. Almost always cheaper than developing a system from scratch

Large complex systems usually consist of a mix of off the shelf and specially designed components. The procurement processes for these different types of component are usually different.


71

The system procurement process


72

Procurement issues

Requirements may have to be modified to match the capabilities of off-the-shelf components.

The requirements specification may be part of the contract for the development of the system.

There is usually a contract negotiation period to agree changes after the contractor to build a system has been selected.


73

Contractors and sub-contractors

The procurement of large hardware/software systems is usually based around some principal contractor.

Sub-contracts are issued to other suppliers to supply parts of the system.

Customer liases with the principal contractor and does not deal directly with sub-contractors.


74

Contractor/Sub-contractor model


75

Legacy systems

Socio-technical systems that have been developed using old or obsolete technology.Crucial to the operation of a business and it is often too risky to discard these systems

Bank customer accounting system;Aircraft maintenance system.

Legacy systems constrain new business processes and consume a high proportion of company budgets.


76


77

Legacy system components

Hardware - may be obsolete mainframe hardware.Support software - may rely on support software from suppliers who are no longer in business.Application software - may be written in obsolete programming languages.Application data - often incomplete and inconsistent.Business processes - may be constrained by software structure and functionality.Business policies and rules - may be implicit and embedded in the system software.


78


79

Key points

Socio-technical systems include computer hardware, software and people and are designed to meet some business goal.Emergent properties are properties that are characteristic of the system as a whole and not its component parts.The systems engineering process includes specification, design, development, integration and testing. System integration is particularly critical.


80

Key points

Human and organisational factors have a significant effect on the operation of socio-technical systems.There are complex interactions between the processes of system procurement, development and operation.A legacy system is an old system that continues to provide essential services.Legacy systems include business processes, application software, support software and system hardware.


81

Critical Systems


82

Objectives

To explain what is meant by a critical system where system failure can have severe human or economic consequence.

To explain four dimensions of dependability - availability, reliability, safety and security.

To explain that, to achieve dependability, you need to avoid mistakes, detect and remove errors and limit damage caused by failure.


83

Topics covered

A simple safety-critical system

System dependability

Availability and reliability

Critical Systems

Safety-critical systemsFailure results in loss of life, injury or damage to the environment;Chemical plant protection system; medical system

Mission-critical systemsFailure results in failure of some goal-directed activity;Spacecraft navigation system;

Business-critical systemsFailure results in high economic losses;Customer accounting system in a bank;NASDAQ trading system


85

System dependability

For critical systems, it is usually the case that the most important system property is the dependability of the system.The dependability of a system reflects the user’s degree of trust in that system. It reflects the extent of the user’s confidence that it will operate as users expect and that it will not ‘fail’ in normal use.Usefulness and trustworthiness are not the same thing. A system does not have to be trusted to be useful.


86

Importance of dependability

Systems that are not dependable and are unreliable, unsafe or insecure may be rejected by their users.

The costs of system failure may be very high (spacecraft).

Undependable systems may cause information loss with a high consequent recovery cost.


87

Development methods for critical systems

The costs of critical system failure are so high that development methods may be used that are not cost-effective for other types of system.

Examples of development methodsFormal methods of software development

Static analysis

External quality assurance

Verification/validation may cost >50% of the development


88

Socio-technical critical systems

Hardware failureHardware fails because of design and manufacturing errors or because components have reached the end of their natural life.

Software failureSoftware fails due to errors in its specification, design or implementation.

Operational failureHuman operators make mistakes. Now perhaps the largest single cause of system failures.


89

A software-controlled insulin pump

Used by diabetics to simulate the function of the pancreas which manufactures insulin, an essential hormone that metabolises blood glucose.

Measures blood glucose (sugar) using a micro-sensor and computes the insulin dose required to metabolise the glucose.


90

Insulin pump organization


91

Insulin pump data-flow


92

Dependability requirements

The system shall be available to deliver insulin when required to do so.

The system shall perform reliability and deliver the correct amount of insulin to counteract the current level of blood sugar.

The essential safety requirement is that excessive doses of insulin should never be delivered as this is potentially life threatening.


93

Dependability

The dependability of a system equates to its trustworthiness.A dependable system is a system that is trusted by its users.Principal dimensions of dependability are:

Availability;Reliability;Safety;Security


94

Dimensions of dependability


95

Other dependability properties

RepairabilityReflects the extent to which the system can be repaired in the event of a failure (Linux vs. Windows)

MaintainabilityReflects the extent to which the system can be adapted to new requirements;

SurvivabilityReflects the extent to which the system can deliver services whilst under hostile attack;

Error toleranceReflects the extent to which user input errors can be avoided and tolerated.


96

Maintainability

A system attribute that is concerned with the ease of repairing the system after a failure has been discovered or changing the system to include new features

Very important for critical systems as faults are often introduced into a system because of maintenance problems (Y2K problem)


97

Survivability

The ability of a system to continue to deliver its services to users in the face of deliberate or accidental attack

This is an increasingly important attribute for distributed systems whose security can be compromised

Survivability subsumes the notion of resilience - the ability of a system to continue in operation in spite of component failures


98

Dependability vs performance

Untrustworthy systems may be rejected by their usersSystem failure costs may be very highIt is very difficult to tune systems to make them more dependableIt may be possible to compensate for poor performanceUntrustworthy systems may cause loss of valuable information


99

Dependability costs

Dependability costs tend to increase exponentially as increasing levels of dependability are requiredThere are two reasons for this

The use of more expensive development techniques and hardware that are required to achieve the higher levels of dependabilityThe increased testing and system validation that is required to convince the system client that the required levels of dependability have been achieved


100

Costs of increasing dependability


101

Dependability economics

Because of very high costs of dependability achievement, it may be more cost effective to accept untrustworthy systems and pay for failure costsHowever, this depends on social and political factors. A reputation for products that can’t be trusted may lose future businessDepends on system type - for business systems in particular, modest levels of dependability may be adequate


102


ReliabilityThe probability of failure-free system operation over a specified time in a given environment for a given purpose

AvailabilityThe probability that a system, at a point in time, will be operational and able to deliver the requested services

Both of these attributes can be expressed quantitatively


103


It is sometimes possible to subsume system availability under system reliability

Obviously if a system is unavailable it is not delivering the specified system services

However, it is possible to have systems with low reliability that must be available. So long as system failures can be repaired quickly and do not damage data, low reliability may not be a problem (Windows)Availability takes repair time into account


104

Reliability terminology


105

Faults and failures

Failures are a usually a result of system errors that are derived from faults in the systemHowever, faults do not necessarily result in system errors

The faulty system state may be transient and ‘corrected’ before an error arises

Errors do not necessarily lead to system failuresThe error can be corrected by built-in error detection and recovery The failure can be protected against by built-in protection facilities. These may, for example, protect system resources from system errors


106

Perceptions of reliability

The formal definition of reliability does not always reflect the user’s perception of a system’s reliability

The assumptions that are made about the environment where a system will be used may be incorrect

Usage of a system in an office environment is likely to be quite different from usage of the same system in a university environment

The consequences of system failures affects the perception of reliability

Unreliable windscreen wipers in a car may be irrelevant in a dry climateFailures that have serious consequences (such as an engine breakdown in a car) are given greater weight by users than failures that are inconvenient


107

Reliability achievement

Fault avoidanceDevelopment technique are used that either minimise the possibility of mistakes or trap mistakes before they result in the introduction of system faults

Fault detection and removalVerification and validation techniques that increase the probability of detecting and correcting errors before the system goes into service are used

Fault toleranceRun-time techniques are used to ensure that system faults do not result in system errors and/or that system errors do not lead to system failures


108

Reliability modelling

You can model a system as an input-output mapping where some inputs will result in erroneous outputsThe reliability of the system is the probability that a particular input will lie in the set of inputs that cause erroneous outputsDifferent people will use the system in different ways so this probability is not a static system attribute but depends on the system’s environment


109

Input/output mapping


110

Reliability perception


111

Reliability improvement

Removing X% of the faults in a system will not necessarily improve the reliability by X%. A study at IBM showed that removing 60% of product defects resulted in a 3% improvement in reliabilityProgram defects may be in rarely executed sections of the code so may never be encountered by users. Removing these does not affect the perceived reliabilityA program with known faults may therefore still be seen as reliable by its users


112

Key points

A critical system is a system where failure can lead to high economic loss, physical damage or threats to life.The dependability in a system reflects the user’s trust in that systemThe availability of a system is the probability that it will be available to deliver services when requestedThe reliability of a system is the probability that system services will be delivered as specifiedReliability and availability are generally seen as necessary but not sufficient conditions for safety and security


113

Key points

Reliability is related to the probability of an error occurring in operational use. A system with known faults may be reliableSafety is a system attribute that reflects the system’s ability to operate without threatening people or the environmentSecurity is a system attribute that reflects the system’s ability to protect itself from external attackDependability improvement requires a socio-technical approach to design where you consider the humans as well as the hardware and software


114

MODULE-2


115

Software Requirements


116

Objectives

To introduce the concepts of user and system requirements

To describe functional and non-functional requirements

To explain how software requirements may be organised in a requirements document


117

Topics covered

Functional and non-functional requirements

User requirements

System requirements

Interface specification

The software requirements document


118

Requirements engineering

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.


119

What is a requirement?

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.This is inevitable as requirements may serve a dual function

May be the basis for a bid for a contract - therefore must be open to interpretation;May be the basis for the contract itself - therefore must be defined in detail;Both these statements may be called requirements.


120

Requirements abstraction (Davis)


121

Types of requirement

User requirementsStatements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

System requirementsA structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.


122

Definitions and specifications

1. T

he software must provide a means of representing and1. accessing external files created by other tools .

1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file .1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.

User requirement definition

System requirements specification


123

Requirements readers

Client managersSystem end-usersClient engineersContractor managersSystem architects

System end-usersClient engineersSystem architectsSoftware developers

Client engineers (perhaps)System architectsSoftware developers

Userrequirements

Systemrequirements

Software designspecification


124

Functional and non-functional requirements

Functional requirementsStatements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

Non-functional requirementsconstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domain.


125

Functional requirements

Describe functionality or system services.

Depend on the type of software, expected users and the type of system where the software is used.

Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail.


126

The LIBSYS system

A library system that provides a single interface to a number of databases of articles in different libraries.

Users can search for, download and print these articles for personal study.


127

Examples of functional requirements

The user shall be able to search either all of the initial set of databases or select a subset from it.

The system shall provide appropriate viewers for the user to read documents in the document store.

Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.


128

Requirements imprecision

Problems arise when requirements are not precisely stated.

Ambiguous requirements may be interpreted in different ways by developers and users.

Consider the term ‘appropriate viewers’User intention - special purpose viewer for each different document type;

Developer interpretation - Provide a text viewer that shows the contents of the document.


129

Requirements completeness and consistency

In principle, requirements should be both complete and consistent.Complete

They should include descriptions of all facilities required.

ConsistentThere should be no conflicts or contradictions in the descriptions of the system facilities.

In practice, it is impossible to produce a complete and consistent requirements document.


130

Non-functional requirements

These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.Process requirements may also be specified mandating a particular CASE system, programming language or development method.Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.


131

Non-functional classifications

Product requirementsRequirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

Organisational requirementsRequirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.

External requirementsRequirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.


132

Non-functional requirement types


133

Non-functional requirements examples

Product requirement8.1 The user interface for LIBSYS shall be implemented as simple

HTML without frames or Java applets.

Organisational requirement9.3.2 The system development process and deliverable documents

shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.

External requirement7.6.5 The system shall not disclose any personal information about

customers apart from their name and reference number to the operators of the system.


134

Goals and requirements

Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. Goal

A general intention of the user such as ease of use.

Verifiable non-functional requirementA statement using some measure that can be objectively tested.

Goals are helpful to developers as they convey the intentions of the system users.


135

Examples

A system goalThe system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised.

A verifiable non-functional requirementExperienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.


136

Requirements measures


137

Requirements interaction

Conflicts between different non-functional requirements are common in complex systems.Spacecraft system

To minimise weight, the number of separate chips in the system should be minimised.To minimise power consumption, lower power chips should be used.However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?


138

Domain requirements

Derived from the application domain and describe system characteristics and features that reflect the domain.

Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.

If domain requirements are not satisfied, the system may be unworkable.


139

Library system domain requirements

There shall be a standard user interface to all databases which shall be based on the Z39.50 standard.

Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.


140

Domain requirements problems

UnderstandabilityRequirements are expressed in the language of the application domain;

This is often not understood by software engineers developing the system.

ImplicitnessDomain specialists understand the area so well that they do not think of making the domain requirements explicit.


141

User requirements

Should describe functional and non-functional requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge.

User requirements are defined using natural language, tables and diagrams as these can be understood by all users.


142

Problems with natural language

Lack of clarity Precision is difficult without making the document difficult to read.

Requirements confusionFunctional and non-functional requirements tend to be mixed-up.

Requirements amalgamationSeveral different requirements may be expressed together.


143

LIBSYS requirement

4..5 LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.


144

Editor grid requirement

2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.


145

Requirement problems

Database requirements includes both conceptual and detailed information

Describes the concept of a financial accounting system that is to be included in LIBSYS;However, it also includes the detail that managers can configure this system - this is unnecessary at this level.

Grid requirement mixes three different kinds of requirement

Conceptual functional requirement (the need for a grid);Non-functional requirement (grid units);Non-functional UI requirement (grid switching).


146

Structured presentation


147

Guidelines for writing requirements

Invent a standard format (template) and use it for all requirements.

Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements.

Use text highlighting to identify key parts of the requirement.

Avoid the use of computer jargon.


148

System requirements

More detailed specifications of system functions, services and constraints than user requirements.They are intended to be a basis for designing the system.They may be incorporated into the system contract.System requirements may be defined or illustrated using system models discussed in Chapter 8.


149

Requirements and design

In principle, requirements should state what the system should do and the design should describe how it does this.In practice, requirements and design are inseparable

A system architecture may be designed to structure the requirements;The system may inter-operate with other systems that generate design requirements;The use of a specific design may be a domain requirement.


150

Problems with NL specification

AmbiguityThe readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult.

Over-flexibilityThe same thing may be said in a number of different ways in the specification.

Lack of modularisationNL structures are inadequate to structure system requirements.


151

Alternatives to NL specification


152

Structured language specifications

The freedom of the requirements writer is limited by a predefined template for requirements.All requirements are written in a standard way.The terminology used in the description may be limited.The advantage is that the most of the expressiveness of natural language is maintained but a degree of uniformity is imposed on the specification.


153

Form-based specifications

Definition of the function or entity.

Description of inputs and where they come from.

Description of outputs and where they go to.

Indication of other entities required.

Pre and post conditions (if appropriate).

The side effects (if any) of the function.


154

Form-based node specification


155

Tabular specification

Used to supplement natural language.

Particularly useful when you have to define a number of possible alternative courses of action.


156

Tabular specification


157

Graphical models

Graphical models are most useful when you need to show how state changes or where you need to describe a sequence of actions.

Different graphical models are explained in Chapter 8.


158

Sequence diagrams

These show the sequence of events that take place during some user interaction with a system.You read them from top to bottom to see the order of the actions that take place.Cash withdrawal from an ATM

Validate card;Handle request;Complete transaction.


159

Sequence diagram of ATM withdrawal


160

Interface specification

Most systems must operate with other systems and the operating interfaces must be specified as part of the requirements.Three types of interface may have to be defined

Procedural interfaces;Data structures that are exchanged;Data representations.

Formal notations are an effective technique for interface specification.


161

An example of interface description


162

The requirements document

The requirements document is the official statement of what is required of the system developers.

Should include both a definition of user requirements and a specification of the system requirements.

It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it


163

Users of a requirements document


164

IEEE requirements standard

Defines a generic structure for a requirements document that must be instantiated for each specific system.

Introduction.General description.Specific requirements.Appendices.Index.


165

Requirements document structure

PrefaceIntroductionGlossaryUser requirements definitionSystem architectureSystem requirements specificationSystem modelsSystem evolutionAppendicesIndex


166

Key points

Requirements set out what the system should do and define constraints on its operation and implementation.Functional requirements set out services the system should provide.Non-functional requirements constrain the system being developed or the development process.User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.


167

Key points

System requirements are intended to communicate the functions that the system should provide.A software requirements document is an agreed statement of the system requirements.The IEEE standard is a useful starting point for defining more detailed specific requirements standards.


168

Project management


169

ObjectivesTo explain the main tasks undertaken by project managersTo introduce software project management and to describe its distinctive characteristicsTo discuss project planning and the planning processTo show how graphical schedule representations are used by project managementTo discuss the notion of risks and the risk management process


170

Topics coveredManagement activities

Project planning

Project scheduling


171

Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.

Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.

Software project management


172

The product is intangible.

The product is uniquely flexible.

Software engineering is not recognized as an engineering discipline with the sane status as mechanical, electrical engineering, etc.

The software development process is not standardised.

Many software projects are 'one-off' projects.

Software management distinctions


173

Proposal writing.

Project planning and scheduling.

Project costing.

Project monitoring and reviews.

Personnel selection and evaluation.

Report writing and presentations.

Management activities


174

These activities are not peculiar to software management.

Many techniques of engineering project management are equally applicable to software project management.

Technically complex engineering systems tend to suffer from the same problems as software systems.

Management commonalities


175

Project staffingMay not be possible to appoint the ideal people to work on a project

Project budget may not allow for the use of highly-paid staff;Staff with the appropriate experience may not be available;An organisation may wish to develop employee skills on a software project.

Managers have to work within these constraints especially when there are shortages of trained staff.


176

Project planningProbably the most time-consuming project management activity.

Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available.

Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget.


177

Types of project plan


178

Project planning processEstablish the project constraints Make initial assessments of the project parameters Define project milestones and deliverableswhile project has not been completed or cancelled loop

Draw up project scheduleInitiate activities according to schedule

Wait ( for a while ) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables if ( problems arise ) then Initiate technical review and possible revision end ifend loop


179

The project plan

The project plan sets out:The resources available to the project;

The work breakdown;

A schedule for the work.


180

Project plan structureIntroduction.

Project organisation.

Risk analysis.

Hardware and software resource requirements.

Work breakdown.

Project schedule.

Monitoring and reporting mechanisms.


181

Activity organizationActivities in a project should be organised to produce tangible outputs for management to judge progress.Milestones are the end-point of a process activity.Deliverables are project results delivered to customers.The waterfall process allows for the straightforward definition of progress milestones.


182

Milestones in the RE process


183

Project schedulingSplit project into tasks and estimate time and resources required to complete each task.

Organize tasks concurrently to make optimal use of workforce.

Minimize task dependencies to avoid delays caused by one task waiting for another to complete.

Dependent on project managers intuition and experience.


184

The project scheduling process


185

Scheduling problemsEstimating the difficulty of problems and hence the cost of developing a solution is hard.

Productivity is not proportional to the number of people working on a task.

Adding people to a late project makes it later because of communication overheads.

The unexpected always happens. Always allow contingency in planning.


186

Bar charts and activity networksGraphical notations used to illustrate the project schedule.

Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two.

Activity charts show task dependencies and the the critical path.

Bar charts show schedule against calendar time.


187

Task durations and dependencies


188

Activity network


189

Activity timeline


190

Staff allocation


191

Risk management

Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.A risk is a probability that some adverse circumstance will occur

Project risks affect schedule or resources;Product risks affect the quality or performance of the software being developed;Business risks affect the organisation developing or procuring the software.


192

Software risks


193

The risk management process

Risk identificationIdentify project, product and business risks;

Risk analysisAssess the likelihood and consequences of these risks;

Risk planningDraw up plans to avoid or minimise the effects of the risk;

Risk monitoringMonitor the risks throughout the project;


194

The risk management process


195

Risk identification

Technology risks.

People risks.

Organisational risks.

Requirements risks.

Estimation risks.


196

Risks and risk types


197

Risk analysis

Assess probability and seriousness of each risk.

Probability may be very low, low, moderate, high or very high.

Risk effects might be catastrophic, serious, tolerable or insignificant.


198

Risk analysis (i)


199

Risk analysis (ii)


200

Risk planning

Consider each risk and develop a strategy to manage that risk.Avoidance strategies

The probability that the risk will arise is reduced;

Minimisation strategiesThe impact of the risk on the project or product will be reduced;

Contingency plansIf the risk arises, contingency plans are plans to deal with that risk;


201

Risk management strategies (i)


202

Risk management strategies (ii)


203

Risk monitoring

Assess each identified risks regularly to decide whether or not it is becoming less or more probable.

Also assess whether the effects of the risk have changed.

Each key risk should be discussed at management progress meetings.


204

Risk indicators


205

Key pointsGood project management is essential for project success.The intangible nature of software causes problems for management.Managers have diverse roles but their most significant activities are planning, estimating and scheduling.Planning and estimating are iterative processes which continue throughout the course of a project.


206

A project milestone is a predictable state where a formal report of progress is presented to management. Project scheduling involves preparing various graphical representations showing project activities, their durations and staffing. Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats.

Key points


207

MODULE -3


208

Rapid Software Development

Friday, December 11,

2020NCET , DEPT. of CSE

221

Objectives

● To explain how an iterative, incremental development process leads to faster delivery of more useful software

● To discuss the essence of agile development methods

● To explain the principles and practices of extreme programming

● To explain the roles of prototyping in the software process

210


Topics covered

● Agile methods● Extreme programming● Rapid application development● Software prototyping

211


Rapid software development● Because of rapidly changing business

environments, businesses have to respond to new opportunities and competition.

● This requires software and rapid development and delivery is not often the most critical requirement for software systems.

● Businesses may be willing to accept lower quality software if rapid delivery of essential functionality is possible.

212


Requirements

● Because of the changing environment, it is often impossible to arrive at a stable, consistent set of system requirements.

● Therefore a waterfall model of development is impractical and an approach to development based on iterative specification and delivery is the only way to deliver software quickly.

213


Characteristics of RAD processes

design and● Theprocesses of specification,implementationare concurrent.There is no detailed specification and design documentation is minimised.

● The system is developed in a series of increments. End users evaluate each increment and make proposals for later increments.

● System user interfaces are usually developed using an interactive development system.

214


An iterative development process

215


Advantages of incremental development

● Accelerated delivery of customer services. Each increment delivers the highest priority functionality to the customer.

● User engagement with the system. Users have to be involved in the development which means the system is more likely to meet their requirements and the users are more committed to the system.

216


Problems with incremental development

● Management problems• Progress can be hard to judge and problems hard to find

because there is no documentation to demonstrate what has been done.

● Contractual problems• The normal contract may include a specification; without a

specification, different forms of contract have to be used.● Validation problems

• Without a specification, what is the system being tested against?

● Maintenance problems• Continual change tends to corrupt software structure making it

more expensive to change and evolve to meet new requirements.

217


Prototyping

● For some large systems, incremental iterative development and delivery may be impractical; this is especially true when multiple teams are working on different sites.

● Prototyping, where an experimentalsystem is

requirements may be used. This system

218

developed as a basis for formulating theis

thrown away when the system specification has been agreed.


Incremental development and prototyping

219


Conflicting objectives

deliver a working system toend-users.

● The objective of incremental development is to

Thedevelopmentstarts with those requirements which are best understood.

● The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood.

220


Agile methods

● Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods:

• Focus on the code rather than the design;• Are based on an iterative approach to software development;• Are intended to deliver working software quickly and evolve this

quickly to meet changing requirements.

● Agile methods are probably best suited to small/medium- sized business systems or PC products.

221


Principles of agile methods

Principle

Customer involvem ent

Incremental delivery

People not pr ocess

Embrac e change

Maintain sim plicity

Description

The c ustomer should be c losely involved throughout thedeve lopm ent process. Their role is provide and prioritise new system req uirements and to evaluate the iterations of the system.

The software is developed in increments w ith the customer specifying the requireme nts to be included in each i ncrement.

The skills of the development tea m should be rec ognised and exploited. T he t eam should be left to develop their own ways of working w ithout prescriptive proce sses.

Expec t the sys tem requirem ents to change and design the sys tem so that it can acc ommodate th ese c han ges.

Focus on sim plicity in both the software be ing deve loped and in the development pr oce ss used. Wherever possible, actively w ork to eliminate com plexity from the system.

222


Problems with agile methods

● It canbe difficult to keep the interestof customerswho are involved in the process.

● Team members may be unsuited to the intense involvement that characterises agile methods.

● Prioritising changes canbe difficult where there are multiple stakeholders.

● Maintaining simplicity requires extra work.● Contracts may be a problem as with other approaches to

iterative development.

223


Extreme programming

● Perhaps thebest-known and most widelyused agile method.

● Extreme Programming (XP) takes an‘extreme’ approach to iterative development.• New versions may be built several times per day;• Increments are delivered to customers every

2 weeks;• All tests must be run for every build and the build is

only accepted if tests run successfully.

224


The extreme programming release cycle225


Extreme programming practices 1

Incr emental plann ing

Small Releas es

Sim ple De sign

Requi rements are record ed on Story Cards and the St ories to be included in a release are de termi ned by the time available and their relative priority. The deve lope rs break these S tories into deve lopment ŌTasks Õ.

The minimal useful set of func tiona lity that prov ides bu sines s va lue is deve loped first. Releas es of the system are frequen t and incrementally add func tiona lity to the first release.

Enough de sign is ca rri ed ou t to m eet the cu rren t requ iremen ts

Test first deve lopmen t

and no more.

An au tomated un it test framewo rk is used to write t ests for a new piece of func tiona lity be fore that fun ction ality itself isimplemented.

Refactoring All deve lope rs are expe cted to refactor the code con tinuous ly as soon as po ssible code improve ments are found . This keeps the code simple and maintainable.


226

Extreme programming practices 2

Pair Progra mmi ng

Co llective Owne rship

Con tinuou s Integr ation

Sustainab le pac e

On - ite Cu stomer

Deve lopers work in pa irs, che cking ea ch otherÕs w ork and providing the suppo rt to always do a good job.

The pa irs of deve lopers wo rk on all areas of the system, so that no islands of expe rtise deve lop and all the deve lope rs own a ll the code . Anyon e can chang e any thing.

As soon as wo rk on a task is complete it is integrated into the who le system. After any such integration, all the un it tests in the system must pass.

Larg e amoun ts of ove r-t ime are not con sidered acceptable as the net effect is often to reduc e code qua lity and medium term produc tivity

A rep resen tative of the end -user o f the system (t he Customershou ld be ava ilable full time for the use of the XP team. In an extreme prog rammi ng p roce ss, the cus tomer is a member of the deve lopmen t team and is respon sible for bringing systemrequ irements to the team for im plementation.

227


XP and agile principles

supported throughsmall,

● Incremental developmentis frequent system releases.

● Customer involvement means full-time customer engagement with the team.

● People not process through pair programming, collective ownership and a process that avoids long working hours.

● Change supported through regular system releases.● Maintainingsimplicity throughconstant refactoring of

code.

228


Requirements scenarios● In XP, user requirements are expressed as

scenarios or user stories.● These are written on cards and the development

team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates.

● The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.

229


Story card for document downloading

230


XP and change

● Conventional wisdom in software engineering is to design for change. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle.

● XP,however,

maintains that this is not

worthwhile as changes cannot be reliablyanticipated.

● Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.

231


Testing in XP

● Test-first development.● Incremental test development from scenarios.● User involvement in test development and

validation.● Automated test harnesses are used to run all

component tests each time that a new release is built.

232


Task cards for document downloading233


Test case description

234


Test-first development

● Writing tests before code clarifies the requirements to be implemented.

● Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly.

● All previous and new tests are automatically run when new functionality is added. Thus checking that the new functionality has not introduced errors.

235


Pair programming● In XP, programmers work in pairs, sitting together

to develop code.● This

spreads knowledge across the teamhelps develop common ownership of code

and.● It serves as an informal review process as each line of

code is looked at by more than 1 person.● It encourages refactoring as the whole team can benefit

from this.● Measurements suggest that development productivity

with pair programming is similar to that of two people working independently.

236


Rapid application development

● Agile methods have received a lot of attention but other approaches to rapid application development have been used for many years.

● These are designed to develop data-intensive business applications and rely on programming and presenting information from a database.

237


RAD environment tools

● Database programming language● Interface generator● Links to office applications● Report generators

238


A RAD environment239


Interface generation

● Many applications are based around complex forms and developing these forms manually is a time-consuming activity.

● RAD environments include support for screen generation including:

• Interactive form definition using drag and drop techniques;• Form linking where the sequence of forms to be presented is

specified;• Form verification where allowed ranges in form fields is defined.

240


Visual programming● Scripting languages such as Visual Basic

support visual programming where the prototype is developed by creating a user interface from standard items and associating components with these items

● A large library of components exists to support this type of development

● These may be tailored to suit the specific application requirements

241


Visual programming with reuse

242


Problems with visual development

● Difficult to coordinate team-based development.● No explicit system architecture.● Complex dependencies between parts of the

program can cause maintainability problems.

243


COTS reuse

● An effective approach to rapid development is to configure and link existing off the shelf systems.

● For example, a requirements management system could be built by using:• A database to store requirements;• A word processor to capturerequirements and

format reports;• A spreadsheet for traceability management;

244


Compound documents

● For some applications, a prototype canbe createdby developing a compound document.

● This is a document with active elements(such as a spreadsheet) that allow user computations.

● Each active element has an associated application which is invoked when that element is selected.

● Thedocument itself is the integrator for the different applications.

245


Application linking246


Software prototyping

● A prototype is an initial version of a system used to demonstrate concepts and try out design options.

● A prototype can be used in:• The requirements engineering process to

help with requirements elicitation and validation;• In design processes to explore options and develop a

UI design;• In the testing process to run back-to-back tests.

247


Benefits of prototyping● Improved system usability.● A closer match to users’ real needs.● Improved design quality.● Improved maintainability.● Reduced development effort.

248


Back to back testing

249


The prototyping process250


Throw-away prototypes

● Prototypes should be discarded after development as they are not a good basis for a production system:• It may be impossible to tune the system to meet non-

functional requirements;• Prototypes are normally undocumented;• The prototype structure is usually degraded through

rapid change;

251

• Theprototype probably will not meet normalorganizational quality standards.


Key points

aimto reduce development overhead andso produce

● An iterativeapproach to software development leadsto faster delivery of software.

● Agile methods are iterativedevelopment methods that

software faster.

252

● Extreme programmingincludessystematic testing, continuous

practices suchas improvementandcustomer involvement.

● The approach to testing in XP is a particular strength where executable tests are developed before the code is written.


Key points

● Rapid application development environments include database programming languages, form generation tools and links to office applications.

● A throw-away prototype is used to explore requirements and design options.

● When implementing a throw-away prototype, start with the requirements you least understand; in incremental development, start with the best- understood requirements.

253


Verification and Validation


254

ObjectivesTo introduce software verification and validation and to discuss the distinction between themTo describe the program inspection process and its role in V & VTo explain static analysis as a verification techniqueTo describe the Cleanroom software development process


255

Topics coveredVerification and validation planning

Software inspections

Automated static analysis

Cleanroom software development


256

Verification: "Are we building the product right”.

The software should conform to its specification.

Validation: "Are we building the right product”.

The software should do what the user really requires.

Verification vs validation


257

Is a whole life-cycle process - V & V must be applied at each stage in the software process.

Has two principal objectivesThe discovery of defects in a system;

The assessment of whether or not the system is useful and useable in an operational situation.

The V & V process


258

V& V goals

Verification and validation should establish confidence that the software is fit for purpose.

This does NOT mean completely free of defects.

Rather, it must be good enough for its intended use and the type of use will determine the degree of confidence that is needed.


259

V & V confidence

Depends on system’s purpose, user expectations and marketing environment

Software functionThe level of confidence depends on how critical the software is to an organisation.

User expectationsUsers may have low expectations of certain kinds of software.

Marketing environmentGetting a product to market early may be more important than finding defects in the program.


260

Software inspections. Concerned with analysis of the static system representation to discover problems (static verification)

May be supplement by tool-based document and code analysis

Software testing. Concerned with exercising and observing product behaviour (dynamic verification)

The system is executed with test data and its operational behaviour is observed

Static and dynamic verification


261

Static and dynamic V&V


262

Can reveal the presence of errors NOT their absence.

The only validation technique for non-functional requirements as the software has to be executed to see how it behaves.

Should be used in conjunction with static verification to provide full V&V coverage.

Program testing


263

Defect testingTests designed to discover system defects.A successful defect test is one which reveals the presence of defects in a system.Covered in Chapter 23

Validation testingIntended to show that the software meets its requirements.A successful test is one that shows that a requirements has been properly implemented.

Types of testing


264

Defect testing and debugging are distinct processes.Verification and validation is concerned with establishing the existence of defects in a program.Debugging is concerned with locating and repairing these errors.Debugging involves formulating a hypothesis about program behaviour then testing these hypotheses to find the system error.

Testing and debugging


265

The debugging process


266

Careful planning is required to get the most out of testing and inspection processes.Planning should start early in the development process.The plan should identify the balance between static verification and testing.Test planning is about defining standards for the testing process rather than describing product tests.

V & V planning


267

The V-model of development


268

The structure of a software test planThe testing process.

Requirements traceability.

Tested items.

Testing schedule.

Test recording procedures.

Hardware and software requirements.

Constraints.


269

The software test plan


270

Software inspections

These involve people examining the source representation with the aim of discovering anomalies and defects.Inspections not require execution of a system so may be used before implementation.They may be applied to any representation of the system (requirements, design,configuration data, test data, etc.).They have been shown to be an effective technique for discovering program errors.


271

Inspection success

Many different defects may be discovered in a single inspection. In testing, one defect ,may mask another so several executions are required.

The reuse domain and programming knowledge so reviewers are likely to have seen the types of error that commonly arise.


272

Inspections and testing

Inspections and testing are complementary and not opposing verification techniques.Both should be used during the V & V process.Inspections can check conformance with a specification but not conformance with the customer’s real requirements.Inspections cannot check non-functional characteristics such as performance, usability, etc.


273

Program inspectionsFormalised approach to document reviews

Intended explicitly for defect detection (not correction).

Defects may be logical errors, anomalies in the code that might indicate an erroneous condition (e.g. an uninitialised variable) or non-compliance with standards.


274

Inspection pre-conditionsA precise specification must be available.Team members must be familiar with the organisation standards.Syntactically correct code or other system representations must be available. An error checklist should be prepared.Management must accept that inspection will increase costs early in the software process.Management should not use inspections for staff appraisal ie finding out who makes mistakes.


275

The inspection process


276

Inspection procedureSystem overview presented to inspection team.Code and associated documents are distributed to inspection team in advance.Inspection takes place and discovered errors are noted.Modifications are made to repair discovered errors.Re-inspection may or may not be required.


277

Inspection roles


278

Inspection checklistsChecklist of common errors should be used to drive the inspection.Error checklists are programming language dependent and reflect the characteristic errors that are likely to arise in the language.In general, the 'weaker' the type checking, the larger the checklist.Examples: Initialisation, Constant naming, loop termination, array bounds, etc.


279

Inspection checks 1


280

Inspection checks 2


281

Inspection rate500 statements/hour during overview.

125 source statement/hour during individual preparation.

90-125 statements/hour can be inspected.

Inspection is therefore an expensive process.

Inspecting 500 lines costs about 40 man/hours effort - about £2800 at UK rates.


282

Automated static analysisStatic analysers are software tools for source text processing.

They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the V & V team.

They are very effective as an aid to inspections - they are a supplement to but not a replacement for inspections.


283

Static analysis checks


284

Stages of static analysisControl flow analysis. Checks for loops with multiple exit or entry points, finds unreachable code, etc.Data use analysis. Detects uninitialised variables, variables written twice without an intervening assignment, variables which are declared but never used, etc.Interface analysis. Checks the consistency of routine and procedure declarations and their use


285

Stages of static analysisInformation flow analysis. Identifies the dependencies of output variables. Does not detect anomalies itself but highlights information for code inspection or review

Path analysis. Identifies paths through the program and sets out the statements executed in that path. Again, potentially useful in the review process

Both these stages generate vast amounts of information. They must be used with care.


286

LINT static analysis


287

Use of static analysis

Particularly valuable when a language such as C is used which has weak typing and hence many errors are undetected by the compiler,

Less cost-effective for languages like Java that have strong type checking and can therefore detect many errors during compilation.


288

Verification and formal methods

Formal methods can be used when a mathematical specification of the system is produced.

They are the ultimate static verification technique.

They involve detailed mathematical analysis of the specification and may develop formal arguments that a program conforms to its mathematical specification.


289

Arguments for formal methods

Producing a mathematical specification requires a detailed analysis of the requirements and this is likely to uncover errors.

They can detect implementation errors before testing when the program is analysed alongside the specification.


290

Arguments against formal methods

Require specialised notations that cannot be understood by domain experts.

Very expensive to develop a specification and even more expensive to show that a program meets that specification.

It may be possible to reach the same level of confidence in a program more cheaply using other V & V techniques.


291

The name is derived from the 'Cleanroom' process in semiconductor fabrication. The philosophy is defect avoidance rather than defect removal.This software development process is based on:

Incremental development;Formal specification;Static verification using correctness arguments;Statistical testing to determine program reliability.

Cleanroom software development


292

The Cleanroom process


293

Cleanroom process characteristics

Formal specification using a state transition model.Incremental development where the customer prioritises increments.Structured programming - limited control and abstraction constructs are used in the program.Static verification using rigorous inspections.Statistical testing of the system (covered in Ch. 24).


294

Formal specification and inspections

The state based model is a system specification and the inspection process checks the program against this mode.l

The programming approach is defined so that the correspondence between the model and the system is clear.

Mathematical arguments (not proofs) are used to increase confidence in the inspection process.


295

Specification team. Responsible for developing and maintaining the system specification.Development team. Responsible for developing and verifying the software. The software is NOT executed or even compiled during this process.Certification team. Responsible for developing a set of statistical tests to exercise the software after development. Reliability growth models used to determine when reliability is acceptable.

Cleanroom process teams


296

The results of using the Cleanroom process have been very impressive with few discovered faults in delivered systems.Independent assessment shows that the process is no more expensive than other approaches.There were fewer errors than in a 'traditional' development process.However, the process is not widely used. It is not clear how this approach can be transferred to an environment with less skilled or less motivated software engineers.

Cleanroom process evaluation


297

Key pointsVerification and validation are not the same thing. Verification shows conformance with specification; validation shows that the program meets the customer’s needs.

Test plans should be drawn up to guide the testing process.

Static verification techniques involve examination and analysis of the program for error detection.


298

Key pointsProgram inspections are very effective in discovering errors.Program code in inspections is systematically checked by a small team to locate software faults.Static analysis tools can discover program anomalies which may be an indication of faults in the code.The Cleanroom development process depends on incremental development, static verification and statistical testing.


299

MODULE 4


300

A perspective on TestingBasic DefinitionTest Cases


301

Why Do we Test.?To make a judgment about quality or acceptability.

Discover Problems


302

Basic Definitions⚫ Error(mistake): mistake while coding-bug⚫ Fault(defect): Result of an error⚪ Fault of omission⚪ Fault of commission

⚫ Failure: A failure occurs when a Fault executes.⚫ Incident: Alerts user occurrence of a Failure⚫ Test: concerned with errors, faults, failures, incident⚫ Test Case: have identity & is associated with a

program behavior. Has i/p & o/p


303


304

Process of testingTest planningTest case developmentRunning test casesEvaluating test results


305

Test Cases


306


307 Component testing

• Component or unit testing is the process of testing individual components in isolation.

• It is a defect testing process.• Components may be:

• Individual functions or methods within an object;• Object classes with several attributes and

methods;• Composite components with defined interfaces

used to access their functionality.


308 Object class testing

• Complete test coverage of a class involves• Testing all operations associated with an object;• Setting and interrogating all object attributes;• Exercising the object in all possible states.

• Inheritance makes it more difficult to design object class tests as the information to be tested is not localised.


309Weather station object interface

WeatherStation

identifier

repor tWeather () calibrate (instruments) test ()star tup (instruments) shutdown (instruments)


310 Weather station testing

• Need to define test cases for reportWeather, calibrate, test, startup and shutdown.

• Using a state model, identify sequences of state transitions to be tested and the event sequences to cause these transitions

• For example:• Waiting > Calibrating > Testing > Transmitting

> Waiting


311

• Objectives are to detect faults due to interface errors or invalid assumptions about interfaces.

• Particularly important for object oriented development as objects are defined by their interfaces.

Interface testing


312 Interface testing


313 Interface types

• Parameter interfaces• Data passed from one procedure to another.

• Shared memory interfaces• Block of memory is shared between procedures or

functions.• Procedural interfaces

• Sub system encapsulates a set of procedures to be called by other sub systems.

• Message passing interfaces• Sub systems request services from other sub system.s


314 Interface errors

• Interface misuse• A calling component calls another component and makes

an error in its use of its interface e.g. parameters in the wrong order.

• Interface misunderstanding• A calling component embeds assumptions about the

behaviour of the called component which are incorrect.• Timing errors

• The called and the calling component operate at different speeds and out of date information is accessed.


315 Interface testing guidelines

• Design tests so that parameters to a called procedure are at the extreme ends of their ranges.

• Always test pointer parameters with null pointers.• Design tests which cause the component to fail.• Use stress testing in message passing systems.• In shared memory systems, vary the order in which

components are activated.


316 Test case design

• Involves designing the test cases (inputs and outputs) used to test the system.

• The goal of test case design is to create a set of tests that are effective in validation and defect testing.

• Design approaches:• Requirements based testing;• Partition testing;• Structural testing.


317Requirements based testing

• A general principle of requirements engineering is that requirements should be testable.

• Requirements based testing is a validation testing technique where you consider each requirement and derive a set of tests for that requirement.


318 LIBSYS requirements

The user shall be able to search either all of the initial set of databases or select a subset from it.

The system shall provide appropriate viewers for the user to read documents in the document store.

Every order shall be allocated a unique identifier (ORDER_ID) that the user shall be able to copy to the accountÕs permanent storage area.


319LIBSYS tests

∙ Initiate user search for searches for items that are known to be present and known not to be present, where the set of databases includes 1 database.

∙ Initiate user searches for items that are known to be presentand known not to be present, where the set of databases includes 2 databases

∙ Initiate user searches for items that are known to be present and known not to be present where the set of databasesincludes more than 2 databases.

∙ Select one database from the set of databases and initiate user searches for items that are known to be present and known not to be present.

∙ Select more than on e database from the set of databases and initiate searches for items that are known to be present and known not to be present.


320 Partition testing

• Input data and output results often fall into different classes where all members of a class are related.

• Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member.

• Test cases should be chosen from each partition.


321 Equivalence partitioning


322 Search routine specification

procedure Search (Key : ELEM ; T: SEQ of ELEM; Found : in out BOOLEAN; L: in out ELEM_INDEX) ;

Pre condition the sequence has at least one element T’FIRST <= T’LAST

Post condition the element is found and is referenced by L ( Found and T (L) = Key)

or the element is not in the array ( not Found andnot (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))


323

• Inputs which conform to the pre conditions.• Inputs where a pre condition does not hold.• Inputs where the key element is a member of

the array.• Inputs where the key element is not a

member of the array.

Search routine input partitions


324 Testing guidelines (sequences)

• Test software with sequences which have only a single value.

• Use sequences of different sizes in different tests.

• Derive tests so that the first, middle and last elements of the sequence are accessed.

• Test with sequences of zero length.


325 Search routine input partitions


326

• Sometime called white box testing.• Derivation of test cases according to

program structure. Knowledge of the program is used to identify additional test cases.

• Objective is to exercise all program statements (not all path combinations).

Structural testing


327 Structural testing


328

• Pre conditions satisfied, key element in array.• Pre conditions satisfied, key element not in

array.• Pre conditions unsatisfied, key element in array.• Pre conditions unsatisfied, key element not in array.• Input array has a single value.• Input array has an even number of values.• Input array has an odd number of values.

Binary search equiv. partitions


329 Binary search equiv. partitions


330 Binary search test cases


331 Path testing

• The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once.

• The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control.

• Statements with conditions are therefore nodes in the flow graph.


332 Binary search flow graph


333

• 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14• 1, 2, 3, 4, 5, 14• 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, …• 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, …• Test cases should be derived so that all of

these paths are executed• A dynamic program analyser may be used to

check that paths have been executed

Independent paths


334 Test automation

• Testing is an expensive process phase. Testing workbenches provide a range of tools to reduce the time required and total testing costs.

• Systems such as Junit support the automatic execution of tests.

• Most testing workbenches are open systems because testing needs are organisation specific.

• They are sometimes difficult to integrate with closed design and analysis workbenches.


335 A testing workbench


336Testing workbench adaptation

• Scripts may be developed for user interface simulators and patterns for test data generators.

• Test outputs may have to be prepared manually for comparison.

• Special purpose file comparators may be developed.


337 Key points

• Testing can show the presence of faults in a system; it cannot prove there are no remaining faults.

• Component developers are responsible for component testing; system testing is the responsibility of a separate team.

• Integration testing is testing increments of the system; release testing involves testing a system to be released to a customer.

• Use experience and guidelines to design test cases in defect testing.


338 Key points

• Interface testing is designed to discover defects in the interfaces of composite components.

• Equivalence partitioning is a way of discovering test cases all cases in a partition should behave in the same way.

• Structural analysis relies on analysing a program and deriving tests from this analysis.

• Test automation reduces testing costs by supporting the test process with a range of software tools.

Boundary value Testing


339

contentsBoundary Value Testing

Boundary Value AnalysisGeneralizing Boundary Value Analysis: variable 4n+1 and range

Limitations of Boundary Value Analysis: independent and physical quantity.

Robustness Testing: Extrema value are exceeded

Worst Case Testing: more than one variable has extreme

value

Special Value Testing: Tester uses his domain knowledge,

experience.


340

Boundary Value TestingAny program can be considered to be a function in the sense that prog. I/p form its domain & prog. o/p form its range. Input domain testing is the best known functional testing technique.


341

For valid user name it should consist characters in the range from 6 to 30


342

Based on 5 elements values of BVA: min-(5) min(6), min+(7), nom(12), max-(29),max(30),max+(31)


343

Boundary Value AnalysisWhen function F is implemented as a pogram, the input variables x1 & x2 will have some boundaries

F(x1, x2), a ≤ x1 ≤ b, c ≤ x2 ≤ d[a,b] [c,d] are ranges of x1 & x2.

Strongly typed languages (Ada, Pascal) permit such variable range.


344

•Input space(domain) of our function F is shown above.•Any point within the shaded rectangle is a legitimate input to the function F.

•Boundary value analysis focuses on the boundary of the input space to identify test cases.


345

Cont.,Errors tend to occur near the extreme values of an input variable

e.g. loop conditions (< instead of ≤), counters

Basic idea: use input variable values at their minimum (min), just above the minimum (min+), a nominal value (nom), just below their maximum (max-), and at their maximum (max).Testing tool (T) generates such Test Cases for Properly specified program. min, min+, max-, max.


346

Cont.,

The boundary value analysis test cases are obtained by holding the values of all but one variable at their nominal values, and letting that variable assume its extreme values


347

Generalizing Boundary value AnalysisGeneralized in 2 ways

No of variables.

Kinds of ranges.

For a function of n variables, boundary value analysis yields 4n+1 unique test cases.


348

Conti.,By the kinds of ranges, depends on the type (nature) of the variables

Variables have discrete, bounded valuese.g. NextDate function, commission problem

Variables have no explicit boundsCreate “artificial” boundse.g. triangle problem

Boolean variablesDecision table-based testing

Logical variables (bound to a value or another logic variable)e.g. PIN and transaction type in SATM System


349

Limitations of Boundary value AnalysisBoundary value analysis works well when the program to be tested is a function of several independent variables that represent bounded physical quantities.

e.g. NextDate test cases are inadequate (little stress on February, dependencies among month, day, and year)

e.g. variables refer to physical quantities, such as temperature, air speed, load etc. {Sky Harbour International Airport 120 deg F eg.)


350

Robustness Testing⚫ Simple extension of boundary value analysis⚫ In addition to the five boundary value analysis

values of a variable, see what happens when the extrema are exceeded with a value slightly greater than the maximum (max+) and a value slightly less than the minimum (min-)

⚫ Focuses on the expected outputs⚪ e.g. exceeding load capacity of a public elevator⚪ May 32 we expect error message.

⚫ Forces attention on exception handling


351

Robustness Testing

Considering min- and max+ values along with 5 elements of BVA


352

Worst-Case TestingWorst case analysis: more than one variable has an extreme valueProcedure:

For each variable create the set <min, min+, nom, max-, max>Take the Cartesian product of these sets to generate test cases

More thorough than boundary value analysisRepresents more effort

For n variables → 5n test cases (as opposed to 4n+1 test cases for boundary value analysis)


353

Worst Case Testing

Taking Cartesian product ofX1:min, min+, nom, max-, maxX2:min,min+, nom, max-, max

5^n


354

Combination of Robust and worst case Testing. 7^n


355

Special value testingThe most widely practiced form of functional testing

Most intuitive, least uniform, no guidelines

The tester uses his/her domain knowledge, experience

with similar programs, “ad hoc testing”

It is dependent on the abilities of the tester

Even though it is highly subjective, it often results in a set of

test cases which is more effective in revealing faults than

the test sets generated by the other methods


356

MODULE-5


357

ContentsEquivalence class.

Weak normal equivalence class testing.

Strong normal equivalence class testing.

Weak Robust equivalence class testing.

Strong Robust equivalence class testing.


358

Equivalence class Testing

– amount <= 1800– 1800 < amount < 15000– amount >= 15000


359


360

Equivalence classes⚫ Motivations⚪ Have a sense of complete testing⚪ Avoid redundancy

⚫ Equivalence classes form a partition of a set, where partition refers to a collection of mutually disjoint subsets whose union is the entire set (completeness, non-redundancy)

⚫ The idea is to identify test cases by using one element from each equivalence class

⚫ The key is the choice of the equivalence relation that determines the classes


361

Equivalence class TestingWhen Function F is implemented as a program, the input variables x1,x2 will have boundaries


362

Weak Normal Equivalence class Testing• Assumes the ‘single fault’ or “independence of input

variables.”• e.g. If there are 2 input variables, these input variables

are independent of each other.

• Partition the test cases of each input variable separately into one of the different equivalent classes.

• Choose the test case from each of the equivalence classes for each input variable independently of the other input variable

• Using 1 variable from each equivalence class(interval) in a test case.


363

Weak Normal Equivalence class test cases

X2

x1

e

f

g

a b c d


364

Strong Normal Equivalence testingMulti Fault assumption.We need Test cases from each element of the Cartesian product of the equivalence classes.The Cartesian product guarantees that we have a notion of completeness in two senses

We cover all the equivalence classes, We have 1 of each possible combination of inputs.


365

Strong Normal Equivalence class test cases

X2

x1

e

f

g

a b c d


366

Weak Robust Equivalence class TestingUp to now we have only considered partitioning the valid input space.

“Weak robust” is similar to “weak normal” equivalence test except that the invalid input variables are now considered.The robust part comes from consideration of invalid values, & the weak part refers to the single fault assumption.


367

weak robust Equivalence class test cases

X2

x1

e

f

g

a b c d


368

Cont.,2 problems occur with robust equivalence testing.

Specification do not define what the expected output for an invalid input should be.

Strongly typed languages eliminate the need for the consideration of invalid inputs.


369

Strong Robust Equivalence TestingRobust part comes from consideration of invalid values,

Strong part refers to the multiple fault assumption.

We obtain test cases from each element of the Cartesian product of all the equivalence classes


370

Strong robust Equivalence class test cases

X2

x1

e

f

g

a b c d


371

contentEquivalence class test cases for

Triangle problem

NextDate Function

Commission problem


372

Equivalence class Test Cases for Triangle problem


373


374


375

Equivalence Class Test Cases for NextDate Function


376


377


378


379

Equivalence Classes


380

Equivalence Class Test Cases


381

Strong Normal Equivalence test case


382

Equivalence Class Test case for commission problem


383

Strong Robust equivalence Test cases


384

Output range equivalence class test cases


385


386

Guidelines & observations


387

Content Decision tables

technique

Test cases for the Triangle problem


388

Decision table based testingUsed to represent & analyze complex logical relationships since the early 1960.

Most rigorous because decision table enforces logical rigor.

2 types of methodsCause effect graphing

Decision tableau method


389

Decision Tables - Structure

Conditions - (Condition stub) Condition Alternatives – (Condition Entry)

Actions – (Action Stub) Action Entries

• Each condition corresponds to a variable, relation or predicate • Possible values for conditions are listed among the condition alternatives

• Boolean values (True / False) – Limited Entry Decision Tables• Several values – Extended Entry Decision Tables• Don’t care value

• Each action is a procedure or operation to perform• The entries specify whether (or in what order) the action is to be performed


390

To express the program logic we can use a limited-entry decision table consisting of 4 areas called the condition stub, condition entry, action stub and the action entry:

Rule1 Rule2 Rule3 Rule4

Condition1 Yes Yes No No

Condition2 Yes X No X

Condition3 No Yes No X

Condition4 No Yes No Yes

Action1 Yes Yes No No

Action2 No No Yes No

Action3 No No No Yes

Condition

stub

Action stub

Action Entry

Condition entry


391

We can specify default rules to indicate the action to be taken when none of the other rules apply.

When using decision tables as a test tool, default rules and their associated predicates must be explicitly provided.

Rule5 Rule6 Rule7 Rule8

Condition1 X No Yes Yes

Condition2 X Yes X No

Condition3 Yes X No No

Condition4 No No Yes X

Default action

Yes Yes Yes Yes


392

Decision Table - Example

Conditions

Printer does not print Y Y Y Y N N N N

A red light is flashing Y Y N N Y Y N N

Printer is unrecognized Y N Y N Y N Y N

Actions

Heck the power cable X

Check the printer-computer cable X X

Ensure printer software is installed X X X X

Check/replace ink X X X X

Check for paper jam X X

Printer Troubleshooting 12/11/2020NCET , DEPT. of CSE

393

Below table tells about the Condition and action to be taken


394


395


396

In mutually exclusive only one condition can be performed at a time.


397


398


399


400


401


402

Test cases for NextDate Function

Equivalence classes

Why many rules were impossible


403

Test cases for NextDate Function


404

Second Try


405


406

Third try


407


408

If the action sets of 2 rule in a limited entry decision table are identical, there must be 1 condition that allow 2 rules to be combined with a don’t care entry


409


410

Test cases for commission problemCommission problem is not well served by decision table analysis.

Very little decision logic is used in the problem


411

DD Paths

Test Coverage metrics

Basis Path testing

content


412

Software Testing


413

G=(V,E)


414

PATH


415

Directed Graph


416

Program graph


417

Program graph

PATH Testing


418


419

Decision-Decision Path

DD Path


420


421

🡪


422


423


424

Test coverage metrics are a device to measure the extent to which a set of test cases covers a program.

425 Test Coverage Metrics


Test Coverage Metrics

Metric Description of Coverage

C0 Every Statement

C1 Every DD-Path

C1P Every predicate to each outcome

C2 C1 Coverage + loop coverage

Cd C1 Coverage + every dependent pair of DD-Paths

CMCC Multiple condition coverage

Cik Every program path that contains up to k repetitions of a loop (usually k=2)

Cstat “Statistically significant” fraction of paths

C∞ All possible execution paths

426


Statement Testing: Every statement is executed by the test set and Predicate Testing: Every logical predicate is executed by the test set

DD path testing: check for all possible paths

Dependent pair of DD-paths: reference/Dependent

Multiple condition coverage: use truth table instead of predicate.

Loop coverage: concatenated, nested, horrible


427

Mathematicians define a basis in terms of a structure called a vector space, which is a set of elements(vectors) as well as operations that correspond to multiplication & addition defined for the vectors.

Basis Path Testing


428

McCabe based his view of testing on a major result from graph theory.

Which states that the cyclomatic no. of a strongly connected graph is the number of linearly independent circuits in the graph.

We can create a strongly connected graph by adding an edge from the(every) sink node to the (every) source node.

McCabe’s basis path method


429

V(G)=e-n+2p; arbitrary directed graph

V(G)=e-n+p; strong directed graph

e– no of edges, n—no of nodes, p—no of connected regions.

Two important points should be made here.

1)if there is a loop, it only has to be traversed once, or else the basis will contain redundant

2)it is possible for there to be more than one basis.

Cont.,


430


431

⚫ The cyclomatic complexity of the strong connected graph is 5; thus there are five linearly independent circuits.

⚫ If we now delete the added edge from node G to node A. these 5 circuits become five linearly independent paths from node A to node G.

⚫ In a small graphs, we can identify independent paths

P1:A,B,C,G

P2:A,B,C,B,C,G

P3:A,B,E,F,G

P4:A,D,E,F,G

P5:A,D,F,G

Cont.,


432

Path addition is simply 1 path followed by another path, & multiplication corresponds to repetitions of a path.

McCabe arrives at a vector space of program paths.

Path A,B,C,B,E,F,G is the basis sum p2+p3-p1 & the path A,B,C,B,C,B,C,G is the linear combination 2p2-p1

Cont.,


433


434

Each decision is “flipped” that is when a node of out degree>=2 is reached, a different edge must be taken.

Cont.,


435

Cont.,


436

Essential Complexity


437


438


439


440

THANK YOU ☺


441

Software Engineering & Testing Course Code: 18CST54

Documents

Transcript of Software Engineering & Testing Course Code: 18CST54