53971072 21378403 Software Engineering by K K Aggarwal YogeshSingh Full Notes

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

1

Why Software Engineering ?Change in nature & complexity of software Concept of one “guru” is over We all want improvement

Ready for changeSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

2

The Evolving Role of SoftwareSoftware industry is in Crisis!success 16%

failure 31%

over budget 53%Source: The Standish Group International, Inc. (CHAOS research)Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

3

The Evolving Role of Software

This is the SORRY state of Software Engineering Today!• Data on 28,000 projects completed in 2000

Completed Late, over budget, and/or with features missing – 49%

Successful – 28%

Cancelled – 23%


4


As per the IBM report, “31%of the project get cancelled before they are completed, 53% overrun their cost estimates by an average of 189% and for every 100 projects, there are 94 restarts”.


5


Hw cost Sw cost

Year 1960 1999 Relative Cost of Hardware and SoftwareSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

6

The Evolving Role of Software• Unlike Hardware– Moore’s law: processor speed/memory capacity doubles every two years


7

The Evolving Role of SoftwareManagers and Technical Persons are asked:Why does it take so long to get the program finished? Why are costs so high? Why can not we find all errors before release? Why do we have difficulty in measuring progress of software development?


8

Factors Contributing to the Software Crisis• Larger problems,

• Lack of adequate training in software engineering, • Increasing skill shortage,

• Low productivity improvements.


9

Some Software failuresAriane 5It took the European Space Agency 10 years and $7 billion to produce Ariane 5, a giant rocket capable of hurling a pair of three-ton satellites into orbit with each launch and intended to give Europe overwhelming supremacy in the commercial space business. The rocket was destroyed after 39 seconds of its launch, at an altitude of two and a half miles along with its payload of four expensive and uninsured scientific satellites.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

10

Some Software failuresWhen the guidance system’s own computer tried to convert one piece of data the sideways velocity of the rocket from a 64 bit format to a 16 bit format; the number was too big, and an overflow error resulted after 36.7 seconds. When the guidance system shutdown, it passed control to an identical, redundant unit, which was there to provide backup in case of just such a failure. Unfortunately, the second unit, which had failed in the identical manner a few milliseconds before.


11

Some Software failuresY2K problem:It was simply the ignorance about the adequacy or otherwise of using only last two digits of the year. The 4-digit date format, like 1964, was shortened to 2-digit format, like 64.


12

Some Software failures The Patriot Missileo First time used in Gulf war o Used as a defense from Iraqi Scud missiles o Failed several times including one that killed 28 US soldiers in Dhahran, Saudi Arabia Reasons: A small timing error in the system’s clock accumulated to the point that after 14 hours, the tracking system was no longer accurate. In the Dhahran attack, the system had been operating for more than 100 hours.


13

Some Software failures The Space ShuttlePart of an abort scenario for the Shuttle requires fuel dumps to lighten the spacecraft. It was during the second of these dumps that a (software) crash occurred. ...the fuel management module, which had performed one dump and successfully exited, restarted when recalled for the second fuel dump...Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

14

Some Software failuresA simple fix took care of the problem…but the programmers decided to see if they could come up with a systematic way to eliminate these generic sorts of bugs in the future. A random group of programmers applied this system to the fuel dump module and other modules. Seventeen additional, previously unknown problems surfaced!


15

Some Software failures Financial SoftwareMany companies have experienced failures in their accounting system due to faults in the software itself. The failures range from producing the wrong information to the whole system crashing.


16

Some Software failures Windows XPo Microsoft released Windows XP on October 25, 2001. o On the same day company posted 18 MB of compatibility patches on the website for bug fixes, compatibility updates, and enhancements. o Two patches fixed important security holes. This is Software Engineering.


17

Bullet” “No Silver Bullet”The hardware cost continues to decline drastically. However, there are desperate cries for a silver bullet something to make software costs drop as rapidly as computer hardware costs do. But as we look to the horizon of a decade, we see no silver bullet. There is no single development, either in technology or in management technique, that by itself promises even one order of magnitude improvement in productivity, in reliability and in simplicity.


18

Bullet” “No Silver Bullet”The hard part of building software is the specification, design and testing of this conceptual construct, not the labour of representing it and testing the correctness of representation. We still make syntax errors, to be sure, but they are trivial as compared to the conceptual errors (logic errors) in most systems. That is why, building software is always hard and there is inherently no silver bullet. While there is no royal road, there is a path forward. Is reusability (and open source) the new silver bullet?Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

19

Bullet” “No Silver Bullet”The blame for software bugs belongs to: • Software companies • Software developers • Legal system • Universities


20

What is software?• Computer programs documentation and associated


21

What is software?

Programs

Documentation

Operating Procedures

Software=Program+Documentation+Operating Procedures Components of softwareSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

22

Documentation consists of different types of manuals areFormal Specification Analysis /Specification ContextDiagram Data Flow Diagrams Design Documentation Manuals Implementation Testing Flow Charts Entity-Relationship Diagram Source Code Listings Cross-Reference Listing Test Data Test Results

List of documentation manualsSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

23

Documentation consists of different types of manuals areSystem Overview User Manuals Beginner’s Guide Tutorial Reference Guide Operating Procedures

Installation Guide Operational Manuals System Administration Guide

List of operating procedure manuals.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

24

Software Product

• 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 –Bespoke (custom) - developed for a single customer according to their specification


25

Software ProductSoftware product is a product designated for delivery to the usersource source codes codes documents documents reports reports manuals manuals data data test results test results prototypes prototypes26

object object codes codes

plans plans

test suites test suites


What is software engineering?Software engineering is an engineering discipline which is concerned with all aspects of software production Software engineers should – adopt a systematic and organised approach to their work – use appropriate tools and techniques depending on • the problem to be solved, • the development constraints and – use the resources availableSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

27

What is software engineering?At the first conference on software engineering in 1968, Fritz Bauer defined software engineering as “The establishment and use of sound engineering principles in order to obtain economically developed software that is reliable and works efficiently on real machines”. Stephen Schach defined the same as “A discipline whose aim is the production of quality software, software that is delivered on time, within budget, and that satisfies its requirements”. Both the definitions are popular and acceptable to majority. However, due to increase in cost of maintaining software, objective is now shifting to produce quality software that is maintainable, delivered on time, within budget, and also satisfies its requirements.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

28

Software ProcessThe software process is the way in which we produce software. Why is it difficult to improve software process ? • Not enough time • Lack of knowledge


29

Software Process• Wrong motivations • Insufficient commitmentImproved future state Initial state state Productivity Process improvement begins

Do not quit here! Learning curve

Time


30

Software Characteristics:Software does not wear out.Burn-in phase

Failure Intensity

Useful life phase

Wear out phase

TimeSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

31

Software Characteristics:Software is not manufactured Reusability of components Software is flexible


32

Software Characteristics:Comparison of constructing a bridge vis-à-vis writing a program.Sr. No 1. 2. 3. 4. 5. 6. 7. Constructing a bridge The problem is well understood There are many existing bridges The requirement for a bridge typically do not change much during construction The strength and stability of a bridge can be calculated with reasonable precision When a bridge collapses, there is a detailed investigation and report Engineers have been constructing bridges for thousands of years Materials (wood, stone,iron, steel) and techniques (making joints in wood, carving stone, casting iron) change slowly. Writing a program Only some parts of the problem are understood, others are not Every program is different and designed for special applications. Requirements typically change during all phases of development. Not possible to calculate correctness of a program with existing methods. When a program fails, the reasons are often unavailable or even deliberately concealed. Developers have been writing programs for 50 years or so. Hardware and software changes rapidly.


33

The Changing Nature of SoftwareSystem Software Engineering and Scientific Software Web based Software Real Time Software Embedded Software Business Software

Artificial Intelligence Personal Software ComputerSoftware


34

The Changing Nature of Software

Trend has emerged to provide source code to the customer and organizations. Software where source codes are available are known as open source software.Examples Open source software: LINUX, MySQL, PHP, Open office, Apache webserver etc.


35

Software Myths (Management Perspectives)Management may be confident about good standards and clear procedures of the company.But the taste of any food item is in the eating; not in the Recipe !


36

Software Myths (Management Perspectives)Company has latest computers and state-ofthe-art software tools, so we shouldn’t worry about the quality of the product.The infrastructure is only one of the several factors that determine the quality of the product!Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

37

Software Myths (Management Perspectives)Addition of more software specialists, those with higher skills and longer experience may bring the schedule back on the track!

Unfortunately, that may further delay the schedule!


38

Software Myths (Management Perspectives)

Software is easy to change

The reality is totally different.


39

Software Myths (Management Perspectives)

Computers provide greater reliability than the devices they replace

This is not always true.


40

Software Myths (Customer Perspectives)A general statement of objectives is sufficient to get started with the development of software. Missing/vague requirements can easily be incorporated/detailed out as they get concretized.

If we do so, we are heading towards a disaster.


41

Software Myths (Customer Perspectives)

Software with more features is better software Software can work right the first time

Both are only myths!


42

Software Myths (Developer Perspectives)

Once the software is demonstrated, the job is done.

Usually, the problems just begin!


43

Software Myths (Developer Perspectives)Software quality can not be assessed before testing.However, quality assessment techniques should be used through out the software development life cycle.


44

Software Myths (Developer Perspectives)The only deliverable for a software development project is the tested code.

Tested code is only one of the deliverable!


45

Software Myths (Developer Perspectives)

Aim is to develop working programs

Those days are over. Now objective is to develop good quality maintainable programs!


46

Some TerminologiesDeliverables and Milestones Different deliverables are generated during software development. The examples are source code, user manuals, operating procedure manuals etc. The milestones are the events that are used to ascertain the status of the project. Finalization of specification is a milestone. Completion of design documentation is another milestone. The milestones are essential for project planning and management.


47

Some TerminologiesProduct and Process Product: What is delivered to the customer, is called a product. It may include source code, specification document, manuals, documentation etc. Basically, it is nothing but a set of deliverables only. Process: Process is the way in which we produce software. It is the collection of activities that leads to (a part of) a product. An efficient process is required to produce good quality products. If the process is weak, the end product will undoubtedly suffer, but an obsessive over reliance on process is also dangerous.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

48

Some TerminologiesMeasures, Metrics and Measurement A measure provides a quantitative indication of the extent, dimension, size, capacity, efficiency, productivity or reliability of some attributes of a product or process. Measurement is the act of evaluating a measure. A metric is a quantitative measure of the degree to which a system, component or process possesses a given attribute.


49

Some TerminologiesSoftware Process and Product Metrics Process metrics quantify the attributes of software development process and environment; whereas product metrics are measures for the software product. Examples Process metrics: Productivity, Quality, Efficiency etc. Product metrics: Size, Reliability, Complexity etc.


50

Some TerminologiesProductivity and Effort Productivity is defined as the rate of output, or production per unit of effort, i.e. the output achieved with regard to the time taken but irrespective of the cost incurred. Hence most appropriate unit of effort is Person Months (PMs), meaning thereby number of persons involved for specified months. So, productivity may be measured as LOC/PM (lines of code produced/person month)


51

Some TerminologiesModule and Software Components There are many definitions of the term module. They range from “a module is a FORTRAN subroutine” to “a module is an Ada Package”, to “Procedures and functions of PASCAL and C”, to “C++ Java classes” to “Java packages” to “a module is a work assignment for an individual developer”. All these definition are correct. The term subprogram is also used sometimes in place of module.


52

Some Terminologies“An independently deliverable piece of functionality providing access to its services through interfaces”. “A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces”.


53

Some TerminologiesGeneric and Customized Software Products Generic products are developed for anonymous customers. The target is generally the entire world and many copies are expected to be sold. Infrastructure software like operating system, compilers, analyzers, word processors, CASE tools etc. are covered in this category. The customized products are developed for particular customers. The specific product is designed and developed as per customer requirements. Most of the development projects (say about 80%)come under this category.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

54

Role of Management in Software Development

Factors

People Product Process

Project


55

Role of Management in Software DevelopmentPeople

1

Project

4

Dependency Order

2

Product

3 Process


56

Multiple Choice QuestionsNote: Select most appropriate answer of the following questions:1.1 Software is (a) Superset of programs (c) Set of programs (b) subset of programs (d) none of the above

1.2 Which is NOT the part of operating procedure manuals? (a) User manuals (b) Operational manuals (c) Documentation manuals (d) Installation manuals 1.3 Which is NOT a software characteristic? (a) Software does not wear out (b) Software is flexible (c) Software is not manufactured (d) Software is always correct 1.4 Product is (a) Deliverables (b) User expectations (c) Organization

�s effort in dev

elopment (d) none of the above 1.5 To produce a good quality product, process should be (a) Complex (b) Efficient (c) Rigorous (d) none of the aboveSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

57

Multiple Choice QuestionsNote: Select most appropriate answer of the following questions:1.6 Which is not a product metric? (a) Size (c) Productivity 1.7 Which is NOT a process metric? (a) Productivity (c) Quality 1.8 Effort is measured in terms of: (a) Person-months (c) Persons 1.9 UML stands for (a) Uniform modeling language (c) Unit modeling language (b) Reliability (d) Functionality (b) Functionality (d) Efficiency (b) Rupees (d) Months (b) Unified modeling language (d) Universal modeling language

1.1 An independently deliverable piece of functionality providing access to its services through interface is called (a) Software measurement (b) Software composition (c) Software measure (d) Software componentSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

58

Multiple Choice QuestionsNote: Select most appropriate answer of the following questions:1.11 Infrastructure software are covered under (a) Generic products (b) Customized products (c) Generic and Customized products (d) none of the above 1.12 Management of software development is dependent on (a) people (b) product (c) process (d) all of the above 1.13 During software development, which factor is most crucial? (a) People (b) Product (c) Process (d) Project 1.14 Program is (a) subset of software (c) software 1.15 Milestones are used to (a) know the cost of the project (c) know user expectations (b) super set of software (d) none of the above (b) know the status of the project (d) none of the above59


Multiple Choice QuestionsNote: Select most appropriate answer of the following questions:1.16 The term module used during design phase refers to (a) Function (b) Procedure (c) Sub program (d) All of the above 1.17 Software consists of (a) Set of instructions + operating system (b) Programs + documentation + operating procedures (c) Programs + hardware manuals (d) Set of programs 1.18 Software engineering approach is used to achieve: (a) Better performance of hardware (b) Error free software (c) Reusable software (d) Quality software product 1.19 Concept of software engineering are applicable to (a) Fortran language only (b) Pascal language only (c) ‘C’ language only (d) All of the above 1.20 CASE Tool is (a) Computer Aided Software Engineering (b) Component Aided Software Engineering (c) Constructive Aided Software Engineering (d)Computer Analysis Software EngineeringSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

60

Exercises1.1 Why is primary goal of software development now shifting from producing good quality software to good quality maintainable software? 1.2 List the reasons for the “software crisis”?Why are CASE tools not normally able to control it? 1.3 “The software crisis is aggravated by the progress in hardware technology?” Explain with examples. 1.4 What is software crisis? Was Y2K a software crisis? 1.5 What is the significance of software crisis in reference to software engineering discipline. 1.6 How are software myths affecting software process? Explain with the help of examples. 1.7 State the difference between program and software. Why have documents and documentation become very important. 1.8 What is software engineering? Is it an art, craft or a science? Discuss.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

61

Exercises1.9 What is aim of software engineering? What does the discipline of software engineering discuss? 1.10 Define the term “Software engineering”. Explain the major differences between software engineering and other traditional engineering disciplines. 1.11 What is software process? Why is it difficult to improve it? 1.12 Describe the characteristics of software contrasting it with the characteristics of hardware. 1.13 Write down the major characteristics of a software. Illustrate with a diagram that the software does not wear out. 1.14 What are the components of a software? Discuss how a software differs from a program. 1.15 Discuss major areas of the applications of the software. 1.16 Is software a product or process? Justify your answer with example


62

Exercises1.17 Differentiate between the following (i) Deliverables and milestones (ii) Product and process (iii) Measures, metrics and measurement 1.18 What is software metric? How is it different from software measurement 1.19 Discuss software process and product metrics with the help of examples. 1.20 What is productivity? How is it related to effort. What is the unit of effort. 1.21 Differentiate between module and software component. 1.22 Distinguish between generic and customized software products. Which one has larger share of market and why? 1.23 Is software a product or process? Justify your answer with exampleSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

63

Exercises1.23 Describe the role of management in software development with the help of examples. 1.24 What are various factors of management dependency in software development. Discuss each factor in detail. 1.25 What is more important: Product or process? Justify your answer.


64


1

Software CertificationWhat is certification? Why should we really need it? Who should carry out this activity? Where should we do such type of certification?


2

Software CertificationTo whom should we target People Process Product We have seen many certified developers (Microsoft certified, Cisco certified, JAVA certified), certified processes (like ISO or CMM) and certified products. There is no clarity about the procedure of software certification.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

People

Process

Product

3

Requirement of CertificationAdam Kalawa of Parasoft has given his views on certification like: “I strongly oppose certification of software developers. I fear that it will bring more harm than good to the software industry. It may further hurt software quality by shifting the blame for bad software. The campaign for certification assumes that unqualified developers cause software problem and that we can improve software quality by ensuring that all developers have the golden stamp of approval. However, improving quality requires improving the production process and integrating in to it practices that reduce the opportunity for introducing defects into the product”


4

Requirement of Certification� How often will developers require certification to keep pace with new technologies? � How will any certification address the issues like fundamentals of computer science, analytical & logical reasoning, programming aptitude & positive attitude? � Process certification alone cannot guarantee high quality product. � Whether we go for certified developers or certified processes? Can independent certification agency provide a fair playing field for each software industry??Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

5

Types of CertificationPeople – Industry specific Process – Industry specific Product – For the customer directly and helps to select a particular product


6

Certification of PersonsThe individual obtaining certification receives the following values: Recognition by peers Increased confidence in personal capabilities Recognition by software industry for professional achievement Improvement in processes Competences maintained through recertification Certification is employees initiated improvement process which improves competence in quality assurances methods & techniques.


7

Certification of PersonsProfessional level of competence in the principles & practices of software quality assurance in the software industry can be achieved by acquiring the designation of: o Certified Software Quality Analyst (CSQA) o Certified Software Tester (CSTE) o Certified Software Project Manager (CSPM) Some company specific certifications are also very popular like Microsoft Office Specialist (MOS) certifications in Word, Excel and PowerPoint. MOS is far best known computer skills certification for administrator.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

8

Certification of ProcessesThe most popular process certification approaches are: ISO 9000 SEI-CMM One should always be suspicious about the quality of end product, however, certification reduces the possibility of poor quality products. Any type of process certification helps to produce good quality and stable software product.


9

Certification of ProductsThis is what is required for the customer. There is no universally accepted product certification scheme. Aviation industry has a popular certification “RTCA DO178B”. The targeted certification level is either A, B, C, D, or E. These levels describe the consequences of a potential failure of the software : catastrophic, hazardous severe, major, minor or no effect.


10

Certification of ProductsDO-178B Records Software Development Plan Software Verification Plan Software Configuration Management Plan Software Quality Assurance Plan Software Requirements Standards Software Design Document Software Verification Test Cases & Products11


Certification of ProductsDO-178B Documents Software Verification Results Problem Report Software Configuration Management Records Software Quality Assurance Records DO-178B certification process is most demanding at higher levels.


12

Certification of ProductsDO-178B level A will: 1. Have largest potential market 2. Require thorough labour intensive preparation of most of the items on the DO-178B support list. DO-178B Level E would: 1. Require fewer support item and 2. Less taxing on company resources.


13

Certification of ProductsWe don’t have product certification in most of the areas. RTOS (real time operating system) is the real-time operating system certification & marked as “LinuxOS-178”. The establishment of independent agencies is a viable option.


14

Third Party Certification for Component base Software EngineeringWeyukar has rightly said “For Component based Software Development (CBO) to revolutionalize software development, developers must be able to produce software significantly cheaper and faster than they otherwise could, even as the resulting software meets the same sort of high reliability standards while being easy to maintain”. Bill council has also given his views as “Currently, there is a little evidences that component based software engineering (CBSE) is revolutionizing software development, and lots of reasons to believe otherwise. I believe the primary reason is that the community is not showing how to develop trusted components”.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

15

Third Party Certification for Component base Software EngineeringContractor: • Gives the standard • Directs any variations in specification • Define patterns • Allowable tolerances • Fix the date of delivery Third party certification is a method to ensure software components conform to well defined standards, based on this certification, trusted assemblies of components can be constructed Third party certification is based on UL 1998, 2nd ed., UL standard for safety for software in programmable component.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

16

Exercises10.1 What is software certification? Discuss its importance in the changing scenario of software industry. 10.2 What are different types of certifications? Explain the significance of each type & which one is most important for the end user. 10.3 What is the role of third party certification in component based software engineering? Why are we not able to stabilize the component based software engineering practices. 10.4 Name few person specific certification schemes. Which one is most popular & why? 10.5 Why customer is only interested in product certification? Discuss any product certification techniques with their generic applicability.


17


1

Software Life Cycle Models

The goal of Software Engineering is to provide models and processes that lead to the production of well-documented maintainable software in a manner that is predictable.


2

Software Life Cycle Models

“The period of time that starts when a software product is conceived and ends when the product is no longer available for use. The software life cycle typically includes a requirement phase, design phase, implementation phase, test phase, installation and check out phase, operation and maintenance phase, and sometimes retirement phase”.


3

Build & Fix ModelProduct is constructed without specifications or any attempt at design Adhoc approach and not well defined Simple two phase modelBuild Code

Fix


4

Build & Fix Model

Suitable for small programming exercises of 100 or 200 lines Unsatisfactory for software for any reasonable size Code soon becomes unfixable & unenhanceable No room for structured design Maintenance is practically not possible


5

Waterfall ModelRequirementAnalysis & Specification

Design

This model is named “waterfall model” because its diagrammatic representation resembles a cascade of waterfalls.Implementation and unit testing Integr ation and system testing Operation and maintenance


6

Waterfall Model

This model is easy to understand and reinforces the notion of “define before design” and “design before code”. The model expects complete & accurate requirements early in the process, which is unrealistic


7

Waterfall ModelProblems of waterfall model i. It is difficult to define all requirements at the beginning of a project

ii. This model is not suitable for accommodating any change iii. A working version of the system is not seen until late in the project’s life iv. It does not scale up well to large projects. v. Real projects are rarely sequential.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

8

Incremental Process ModelsThey are effective in the situations where requirements are defined precisely and there is no confusion about the functionality of the final product. After every cycle a useable product is given to the customer. Popular particularly when we have to quickly deliver a limited functionality system.


9

Iterative Enhancement ModelThis model has the same phases as the waterfall model, but with fewer restrictions. Generally the phases occur in the same order as in the waterfall model, but they may be conducted in several cycles. Useable product is released at the end of the each cycle, with each release providing additional functionality. Customers and developers specify as many requirements as possible and prepare a SRS document. Developers and customers then prioritize these requirements Developers implement the specified requirements in one or more cycles of design, implementation and test based on the defined priorities.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

10

Iterative Enhancement ModelRequirements specification

Architectural design

Detailed

design

Implementation and unit testing

Integration and testing

Operation and Maintenance


11

The Rapid Application Development (RAD) Modelo o Developed by IBM in 1980 User participation is essential

The requirements specification was defined like this

The developers understood it in that way

This is how the problem was solved before.

This is how the problem is solved now

This is how the program is This, in fact, is what the described by marketing customer wanted … That is the program after debugging Engineering (3 ed.), By K.K Aggarwaldepartment © New Age International Publishers, 2007 Software & Yogesh Singh, Copyrightrd

12

The Rapid Application Development (RAD) Modelo o o Build a rapid prototype Give it to user for evaluation & obtain feedback Prototype is refined With active participation of users

Requirements Planning

User Description

Construction

Cut over


13

The Rapid Application Development (RAD) Model

Not an appropriate model in the absence of user participation. Reusable components are required to reduce development time. Highly specialized & skilled developers are required and such developers are not easily available.


14

Evolutionary Process ModelsEvolutionary process model resembles iterative enhancement model. The same phases as defined for the waterfall model occur here in a cyclical fashion. This model differs from iterative enhancement model in the sense that this does not require a useable product at the end of each cycle. In evolutionary development, requirements are implemented by category rather than by priority. This model is useful for projects using new technology that is not well understood. This is also used for complex projects where all functionality must be delivered at one time, but the requirements are unstable or not well understood at the beginning.


15

Evolutionary Process ModelConcurr ent activities Initial version

Specification

Outline description

Development

Intermediate versions

Validation

Final version


16

Prototyping Model

The prototype may be a usable program but is not suitable as the final software product. The code for the prototype is thrown away. However experience gathered helps in developing the actual system. The development of a prototype might involve extra cost, but overall cost might turnout to be lower than that of an equivalent system developed using the waterfall model.


17

Prototyping Model

• Linear model • “Rapid”


18

Spiral ModelModels do not deal with uncertainly which is inherent to software projects. Important software projects have failed because project risks were neglected & nobody was prepared when something unforeseen happened. Barry Boehm recognized this and tired to incorporate the “project risk” factor into a life cycle model. The result is the spiral model, which was presented in 1986.


19

Spiral Model


20

Spiral ModelThe radial dimension of the model represents the cumulative costs. Each path around the spiral is indicative of increased costs. The angular dimension represents the progress made in completing each cycle. Each loop of the spiral from X-axis clockwise through 360o represents one phase. One phase is split roughly into four sectors of major activities. Planning: Determination constraints. of objectives, alternatives &

Risk Analysis: Analyze alternatives and attempts to identify and resolve the risks involved. Development: Product development and testing product. Assessment: Customer evaluationSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

21

Spiral ModelAn important feature of the spiral model is that each phase is completed with a review by the people concerned with the project (designers and programmers) The advantage of this model is the wide range of options to accommodate the good features of other life cycle models. It becomes equivalent to another life cycle model in appropriate situations. The spiral model has some difficulties that need to be resolved before it can be a universally applied life cycle model. These difficulties include lack of explicit process guidance in determining objectives, constraints, alternatives; relying on risk assessment expertise; and provides more flexibility than required for many applications.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

22

The Unified Process• Developed by I.Jacobson, G.Booch and J.Rumbaugh. • Software engineering process with the goal of producing good quality maintainable software within specified time and budget.

• Developed through a series of fixed length mini projects called iterations. • Maintained and enhanced by Rational Software Corporation and thus referred to as Rational Unified Process (RUP).


23

Phases of the Unified Process

InceptionTime

Elaboration

Construction

Transition

Definition of objectives of the project

Planning & architecture for the project

Initial operational capability

Release of the Software product


24

Phases of the Unified Process• Inception: defines scope of the project. • Elaboration - How do we plan & design the project? - What resources are required? - What type of architecture may be suitable? • Construction: the objectives are translated in design & architecture documents. • Transition : involves many activities like delivering, training, supporting, and maintaining the product.


25

Initial development & Evolution Cycles

V1

Inception

Elaboration

Construction

TransitionV2

Initial development Cycle

Inception

Elaboration

Construction

Transition

Evolution Cycle

Inception

Elaboration

Construction

Transition

V3

Continue till the product is retired

V1=version1, V2 =version2, V3=version3Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

26

Iterations & Workflow of Unified Process


27

Inception PhaseThe inception phase has the following objectives: Gathering and analyzing the requirements. Planning and preparing a business case and evaluating alternatives for risk management, scheduling resources etc. Estimating the overall cost and schedule for the project. Studying the feasibility and calculating profitability of the project.


28

Outcomes of Inception Phase

Prototypes Business model Vision document Inception

Project plan Initial risk assessment

Initial business case Initial Initial use case model project Glossary


29

Elaboration PhaseThe elaboration phase has the following objectives: Establishing architectural foundations. Design of use case model. Elaborating the process, infrastructure & development environment. Selecting component. Demonstrating that architecture support the vision at reasonable cost & within specified time.


30

Outcomes of Elaboration Phase

Development plan Preliminary User manual Use case model Elaboration

Supplementary Requirements with non functional requirement

Revised risk document An executable architectural prototype Architecture Description document


31

Construction PhaseThe construction phase has the following objectives: Implementing the project. Minimizing development cost. Management and optimizing resources. Testing the product Assessing the product releases against acceptance criteria


32

Outcomes of Construction PhaseTest Outline Documentation manuals Software product Construction

Operational manuals Test Suite A description of the current release

User manuals


33

Transition PhaseThe transition phase has the following objectives: Starting of beta testing Analysis of user’s views. Training of users. Tuning activities including bug fixing and enhancements for performance & usability Assessing the customer satisfaction.


34

Outcomes of Transition Phase

Transition

Product release

Beta test reports

User feedback


35

Selection of a Life Cycle ModelSelection of a model is based on:a) Requirements b) Development team c) Users d) Project type and associated risk


36

Based On Characteristics Of RequirementsRequirements Waterfall Prototype Iterative enhancement Evolutionary development Spiral RAD

Are requirements easily understandable and defined? Do we change requirements quite often? Can we define requirements early in the cycle? Requirements are indicating a complex system to be built

Yes

No

No

No

No

Yes

No

Yes

No

No

Yes

No

Yes

No

Yes

Yes

No

Yes

No

Yes

Yes

Yes

Yes

No


37

Based On Status Of Development TeamDevelopment team Waterfall Prototype Iterative enhancement Evolutionary development Spiral RAD

Less experience on similar projects? Less domain knowledge (new to the technology) Less experience on tools to be used

No

Yes

No

No

Yes

No

Yes

No

Yes

Yes

Yes

No

Yes

No

No

No

Yes

No

Availability of training if required

No

No

Yes

Yes

No

Yes


User’ Based On User’s ParticipationInvolvement of Users Waterfall Prototype Iterative enhancement Evolutionary development Spiral RAD

User involvement in all phases Limited user participation User have no previous experience of participation in similar projects Users are experts of problem domain

No

Yes

No

No

No

Yes

Yes

No

Yes

Yes

Yes

No

No

Yes

Yes

Yes

Yes

No

No

Yes

Yes

Yes

No

Yes


39

Based On Type Of Project With Associated RiskProject type and risk Project is the enhancement of the existing system Funding is stable for the project High reliability requirements Tight project schedule Use of reusable components Are resources (time, money, people etc.) scare? Waterfall Prototype Iterative enhancement Evolutionary development Spiral RAD

No

No

Yes

Yes

No

Yes

Yes No No No No

Yes No Yes Yes Yes

No Yes Yes No No

No Yes Yes No No

No Yes Yes Yes Yes

Yes No Yes Yes No


40

Multiple Choice QuestionsNote: Select most appropriate answer of the following questions:2.1 Spiral Model was developed by (a) Bev Littlewood (b) Berry Boehm (c) Roger Pressman (d) Victor Basili 2.2 Which model is most popular for student’s small projects? (a) Waterfall model (b) Spiral model (c) Quick and fix model (d) Prototyping model 2.3 Which is not a software life cycle model? (a) Waterfall model (b) Spiral model (c) Prototyping model (d) Capability maturity model 2.4 Project risk factor is considered in (a) Waterfall model (b) Prototyping model (c) Spiral model (d) Iterative enhancement model 2.5 SDLC stands for (a) Software design life cycle (b) Software development life cycle (c) System development life cycle (d) System design life cycle


41

Multiple Choice QuestionsNote: Select most appropriate answer of the following questions:2.6 Build and fix model has (a) 3 phases (c) 2 phases 2.7 SRS stands for (a) Software requirements specification (c) System requirements specification 2.8 Waterfall model is not suitable for (a) small projects (c) complex projects 2.9 RAD stands for (a) Rapid application development (c) Ready application development 2.10 RAD model was proposed by (a) Lucent Technologies (c) IBM (b) 1 phase (d) 4 phases (b) Software requirements solution (d) none of the above (b) accommodating change (d) none of the above (b) Relative application development (d) Repeated application development (b) Motorola (d) Microsoft


42

Multiple Choice QuestionsNote: Select most appropriate answer of the following questions:2.11 If requirements are easily understandable and defined,which model is best suited? (a) Waterfall model (b) Prototyping model (c) Spiral model (d) None of the above 2.12 If requirements are frequently changing, which model is to be selected? (a) Waterfall model (b) Prototyping model (c) RAD model (d) Iterative enhancement model 2.13 If user participation is available, which model is to be chosen? (a) Waterfall model (b) Iterative enhancement model (c) Spiral model (d) RAD model 2.14 If limited user participation is available, which model is to be selected? (a) Waterfall model (b) Spiral model (c) Iterative enhancement model (d) any of the above 2.15 If project is the enhancement of existing system, which model is best suited? (a) Waterfall model (b) Prototyping model (c) Iterative enhancement model (d) Spiral model


43

Multiple Choice QuestionsNote: Select most appropriate answer of the following questions:2.16 Which one is the most important feature of spiral model? (a) Quality management (b) Risk management (c) Performance management (d) Efficiency management 2.17 Most suitable model for new technology that is not well understood is: (a) Waterfall model (b) RAD model (c) Iterative enhancement model (d) Evolutionary development model 2.18 Statistically, the maximum percentage of errors belong to the following phase of SDLC (a) Coding (b) Design (c) Specifications (d) Installation and maintenance 2.19 Which phase is not available in software life cycle? (a) Coding (b) Testing (c) Maintenance (d) Abstraction 2.20 The development is supposed to proceed linearly through the phase in (a) Spiral model (b) Waterfall model (c) Prototyping model (d) None of the above


44

Multiple Choice QuestionsNote: Select most appropriate answer of the following questions:2.21 Unified process is maintained by (a) Infosys (b) Rational software corporation (c) SUN Microsystems (d) None of the above 2.22 Unified process is (a) Iterative (b) Incremental (c) Evolutionary (d) All of the above 2.23 Who is not in the team of Unified process development? (a) I.Jacobson (b) G.Booch (c) B.Boehm (d) J.Rumbaugh 2.24 How many phases are in the unified process? (a) 4 (b) 5 (c) 2 (d) None of the above 2.25 The outcome of construction phased can be treated as: (a) Product release (b) Beta release (c) Alpha release (d) All of the above


45

Exercises2.1 What do you understand by the term Software Development Life Cycle (SDLC)? Why is it important to adhere to a life cycle model while developing a large software product? 2.2 What is software life cycle? Discuss the generic waterfall model. 2.3 List the advantages of using waterfall model instead of adhoc build and fix model. 2.4 Discuss the prototyping model. What is the effect of designing a prototype on the overall cost of the project? 2.5 What are the advantages of developing the prototype of a system? 2.6 Describe the type of situations where iterative enhancement model might lead to difficulties. 2.7 Compare iterative enhancement model and evolutionary process model.


46

Exercises2.8 Sketch a neat diagram of spiral model of software life cycle. 2.9 Compare the waterfall model and the spiral model of software development. 2.10 As we move outward along with process flow path of the spiral model, what can we say about software that is being developed or maintained. 2.11 How does “project risk” factor effect the spiral model of software development. 2.12 List the advantages and disadvantages of involving a software engineer throughout the software development planning process. 2.13 Explain the spiral model of software development. What are the limitations of such a model? 2.14 Describe the rapid application development (RAD) model.Discuss each phase in detail. 2.15 What are the characteristics to be considered for the selection of the life cycle model?


47

Exercises2.16 What is the role of user participation in the selection of a life cycle model?. 2.17 Why do we feel that characteristics of requirements play a very significant role in the selection of a life cycle model? 2.18 Write short note on “status of development team” for the selection of a life cycle model?. 2.19 Discuss the selection process parameters for a life cycle model. 2.20 What is unified process? Explain various phases along with the outcome of each phase. 2.21 Describe the unified process work products after each phase of unified process. 2.22 What are the advantages of iterative approach over sequential approach? Why is unified process called as iterative or incremental?


48


1

Requirement EngineeringRequirements describe What not How

Produces one large document written in natural language contains a description of what the system will do without describing how it will do it. Crucial process steps Quality of product Without well written document -- Developers do not know what to build -- Customers do not know what to expect -- What to validateSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

Process that creates it

2

Problem Statement

Requirements Elicitation

Requirement Engineering

Requirements Analysis

Requirements Documentation

SRS

Requirements Review

Crucial Process Steps of requirement engineeringSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

3

Requirement EngineeringRequirement Engineering is the disciplined application of proven principles, methods, tools, and notations to describe a proposed system’s intended behavior and its associated constraints. SRS may act as a contract between developer and customer.

State of practiceRequirements are difficult to uncover • Requirements change • Over reliance on CASE Tools • Tight project Schedule • Communication barriers • Market driven software development • Lack of resourcesSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

4

Requirement EngineeringExampleA University wish to develop a software system for the student result management of its M.Tech. Programme. A problem statement is to be prepared for the software development company. The problem statement may give an overview of the existing system and broad expectations from the new software system.


5

Types of RequirementsTypes of Requirements

Known Requirements

Unknown Requirements

Undreamed Requirements

Stakeholder: Anyone who should have some direct or indirect influence on the system requirements. --- User --- Affected persons

Requirements

Functional

Non-Functional6


Types of RequirementsFunctional requirements describe what the software has to do. They are often called product features. Non Functional requirements are mostly quality requirements. That stipulate how well the software does, what it has to do.Availability Reliability Usability Flexibility For Users

Maintainability Portability Testability

For Developers


7

Types of RequirementsUser and system requirements• User requirement are written for the users and include functional and non functional requirement. • System requirement are derived from user requirement. • The user system requirements are the parts of software requirement and specification (SRS) document.


8

Types of RequirementsInterface Specification• Important for the customers.TYPES OF INTERFACES

• Procedural interfaces (also Programming Interfaces (APIs)). • Data structures • Representation of data.

called

Application


9

Feasibility StudyIs cancellation of a project a bad news?As per IBM report, “31% projects get cancelled before they are completed, 53% over-run their cost estimates by an average of 189% & for every 100 projects, there are 94 restarts.

How do we cancel a project with the least work?

CONDUCT A FEASIBILTY STUDY


10

Feasibility StudyTechnical feasibility

• Is it technically feasible to provide direct communication connectivity through space from one location of globe to another location?

• Is it technically feasible to design a programming language using “Sanskrit”?


11

Feasibility StudyFeasibility depends upon non technical Issues like:• Are the project’s cost and schedule assumption realistic? • Does the business model realistic? • Is there any market for the product?


12

Feasibility StudyPurpose of feasibility study“evaluation or analysis of the potential impact of a proposed project or program.”

Focus of feasibility studies• Is the product concept viable? • Will it be possible to develop a product that matches the project’s vision statement? • What are the current estimated cost and schedule for the project?Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

13

Feasibility StudyFocus of feasibility studies• How big is the gap between the original cost & schedule targets & current estimates? • Is the business model for software justified when the current cost & schedule estimate are considered? • Have the major risks to the project been identified & can they be surmounted? • Is the specifications complete & stable enough to support remaining development work?


14

Feasibility StudyFocus of feasibility studies• Have users & developers been able to agree on a detailed user interface prototype? If not, are the requirements really stable? • Is the software development plan complete & adequate to support further development work?


15

Requirements ElicitationPerhaps • Most difficult • Most critical • Most error prone • Most communication intensive Succeed effective customer developer partnership Selection of any method 1. It is the only method that we know 2. It is our favorite method for all situations 3. We understand intuitively that the method is effective in the present circumstances. Normally we rely on first two reasons.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

16

Requirements Elicitation1. InterviewsBoth parties have a common goal --- open ended --- structured Interview Success of the project

Selection of stakeholder1. Entry level personnel 2. Middle level stakeholder 3. Managers 4. Users of the software (Most important)Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

17

Requirements ElicitationTypes of questions. • Any problems with existing system • Any Calculation errors • Possible reasons for malfunctioning • No. of Student Enrolled


18

Requirements Elicitation5. Possible benefits 6. Satisfied with current policies 7.How are you maintaining the records of previous students? 8. Any requirement of data from other system 9. Any specific problems 10. Any additional functionality 11. Most important goal of the proposed development At the end, we may have wide variety of expectations from the proposed software.


19

Requirements Elicitation2. Brainstorming SessionsIt is a group technique group discussionsNew ideas Quickly Creative Thinking

Prepare long list of requirements Categorized Prioritized Pruned *Idea is to generate views ,not to vet them. Groups 1. Users 2. Middle Level managers 3. Total StakeholdersSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

20

Requirements ElicitationA Facilitator may handle group bias, conflicts carefully. -- Facilitator may follow a published agenda -- Every idea will be documented in a way that everyone can see it. --A detailed report is prepared. 3. Facilitated Application specification Techniques (FAST) -- Similar to brainstorming sessions. -- Team oriented approach -- Creation of joint team of customers and developers.


21

Requirements ElicitationGuidelines1. Arrange a meeting at a neutral site. 2. Establish rules for participation. 3. Informal agenda to encourage free flow of ideas. 4. Appoint a facilitator. 5. Prepare definition mechanism board, worksheets, wall stickier. 6. Participants should not criticize or debate.

FAST session PreparationsEach attendee is asked to make a list of objects that are:Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

22

Requirements Elicitation1. Part of environment that surrounds the system. 2. Produced by the system. 3. Used by the system. A. List of constraints B. Functions C. Performance criteria Activities of FAST session 1. Every participant presents his/her list 2. Combine list for each topic 3. Discussion 4. Consensus list 5. Sub teams for mini specifications 6. Presentations of mini-specifications 7. Validation criteria 8. A sub team to draft specificationsSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

23

Requirements Elicitation4. Quality Function Deployment-- Incorporate voice of the customer Technical requirements. Documented Prime concern is customer satisfaction What is important for customer? -- Normal requirements -- Expected requirements -- Exciting requirements


24

Requirements ElicitationSteps1. Identify stakeholders 2. List out requirements 3. Degree of importance to each requirement.


25

Requirements Elicitation5 4 3 2 1 V. Important Important Not Important but nice to have Not important Unrealistic, required further exploration Requirement Engineer may categorize like: (i) It is possible to achieve (ii) It should be deferred & Why (iii) It is impossible and should be dropped from consideration First Category requirements will be implemented as per priority assigned with every requirement.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

Points Points Points Points Points

: : : : :

26

Requirements Elicitation5. The Use Case ApproachIvar Jacobson & others introduced Use Case approach for elicitation & modeling. Use Case – give functional view The terms Use Case Use Case Scenario Use Case Diagram Often Interchanged But they are different

Use Cases are structured outline or template for the description of user requirements modeled in a structured language like English.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

27

Requirements ElicitationUse case Scenarios are unstructured descriptions of user requirements. Use case diagrams are graphical representations that may be decomposed into further levels of abstraction.

Components of Use Case approachActor: An actor or external agent, lies outside the system model, but interacts with it in some way. Actor Person, machine, information SystemSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

28

Requirements Elicitation• Cockburn distinguishes secondary actors. between Primary and

• A Primary actor is one having a goal requiring the assistance of the system. • A Secondary actor is one from which System needs assistance.

Use CasesA use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied.


29

Requirements Elicitation* It describes the sequence of interactions between actors and the system necessary to deliver the services that satisfies the goal. * Alternate sequence * System is treated as black box.

Thus Use Case captures who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals.


30

Requirements Elicitation*defines all behavior required of the system, bounding the scope of the system. Jacobson & others proposed a template for writing Use cases as shown below:1. Introduction Describe a quick background of the use case. 2.Actors List the actors that interact and participate in the use cases. 3.Pre Conditions Pre conditions that need to be satisfied for the use case to perform. 4. Post Conditions Define the different states in which we expect the system to be in, after the use case executes.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

31

Requirements Elicitation5. Flow of events 5.1 Basic Flow List the primary events that will occur when this use case is executed. 5.2 Alternative Flows Any Subsidiary events that can occur in the use case should be separately listed. List each such event as an alternative flow. A use case can have many alternative flows as required. 6.Special Requirements Business rules should be listed for basic & information flows as special requirements in the use case narration .These rules will also be used for writing test cases. Both success and failures scenarios should be described. 7.Use Case relationships For Complex systems it is recommended to document the relationships between use cases. Listing the relationships between use cases also provides a mechanism for traceability


Use Case Template.

32

Requirements ElicitationUse Case Guidelines1. Identify all users 2. Create a user profile for each category of users including all roles of the users play that are relevant to the system. 3. Create a use case for each goal, following the use case template maintain the same level of abstraction throughout the use case. Steps in higher level use cases may be treated as goals for lower level (i.e. more detailed), subuse cases. 4. Structure the use case 5. Review and validate with users.


33

Requirements ElicitationUse case Diagrams-- represents what happens when actor interacts with a system. -- captures functional aspect of the system.

Actor

Use Case

Relationship between actors and use case and/or between the use cases.

-- Actors

appear outside the rectangle.

--Use cases within rectangle providing functionality. --Relationship association is a solid line between actor & use cases.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

34

Requirements Elicitation*Use cases should not be used to capture all the details of the system. *Only significant aspects of the required functionality *No design issues *Use Cases are for “what” the system is , not “how” the system will be designed * Free of design characteristicsSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

35

Use case diagram for Result Management SystemMaintain Student Details

Maintain Subject Details Data Entry Operator Maintain Result Details

LoginAdministrator/DR Generate Result Reports

View Results Student/TeacherSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

36

Requirements Elicitation1. Maintain student Details Add/Modify/update students details like name, address. 2.Maintain subject Details Add/Modify/Update Subject information semester wise 3.Maintain Result Details Include entry of marks and assignment of credit points for each paper. 4. Login Use to Provide way to enter through user id & password. 5. Generate Result Report Use to print various reports 6. View Result (i) According to course code (ii) According to Enrollment number/roll numberSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

37

Requirements Elicitation (Use Case)Login1.1 Introduction : This use case describes how a user logs into the Result Management System. 1.2 Actors : (i) (ii) Data Entry Operator Administrator/Deputy Registrar

1.3 Pre Conditions : None 1.4 Post Conditions : If the use case is successful, the actor is logged into the system. If not, the system state is unchanged.


38

Requirements Elicitation (Use Case)1.5 Basic Flow : This use case starts when the actor wishes to login to the Result Management system.

(i) System requests that the actor enter his/her name and password. (ii) The actor enters his/her name & password. (iii) System validates name & password, and if finds correct allow the actor to logs into the system.


39

Use Cases1.6 Alternate Flows 1.6.1 Invalid name & password If in the basic flow, the actor enters an invalid name and/or password, the system displays an error message. The actor can choose to either return to the beginning of the basic flow or cancel the login, at that point, the use case ends. 1.7 Special Requirements: None 1.8 Use case Relationships: NoneSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

40

Use Cases2.Maintain student details2.1 Introduction : Allow DEO to maintain student details. This includes adding, changing and deleting student information

2.2

Actors

:

DEO

2.3 Pre-Conditions: DEO must be logged onto the system before this use case begins.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

41

Use Cases2.4 Post-conditions : If use case is successful, student information is added/updated/deleted from the system. Otherwise, the system state is unchanged. 2.5 Basic Flow : Starts when DEO add/modify/update/delete Student information. wishes to

(i) The system requests the DEO to specify the function, he/she would like to perform (Add/update/delete) (ii) One of the sub flow will execute after getting the information.


42

Use CasesIf DEO selects "Add a student", "Add a student" sub flow will be executed. If DEO selects "update a student", "update a student" sub flow will be executed. If DEO selects "delete a student", "delete a student" sub flow will be executed. 2.5.1 Add a student (i) The system requests the DEO to enter: Name Address Roll No Phone No Date of admission (ii) System generates unique idSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

43

Use Cases2.5.2 Update a student(i) System requires the DEO to enter student-id. (ii) DEO enters the student_id. The system retrieves and display the student information. (iii) DEO makes the desired changes to the student information. (iv) After changes, the system updates the student record with changed information.


44

Use Cases2.5.3 Delete a student(i) The system requests the DEO to specify the student-id. (ii) DEO enters the student-id. The system retrieves and displays the student information. (iii) The system prompts the DEO to confirm the deletion of the student. (iv) The DEO confirms the deletion. (v) The system marks the student record for deletion.


45

Use Cases2.6 Alternative flows

2.6.1 Student not found If in the update a student or delete a student sub flows, a student with specified_id does not exist, the system displays an error message .The DEO may enter a different id or cancel the operation. At this point ,Use case ends.


46

Use Cases2.6.2 Update Cancelled If in the update a student sub-flow, the data entry operator decides not to update the student information, the update is cancelled and the basic flow is restarted at the begin.


47

Use Cases2.6.3 Delete cancelled If in the delete a student sub flows, DEO decides not to delete student record ,the delete is cancelled and the basic flow is re-started at the beginning. 2.7 Special requirements None 2.8 Use case relationships None


48

Use Cases3. Maintain Subject Details3.1 Introduction The DEO to maintain subject information. This includes adding, changing, deleting subject information from the system 3.2 3.3 Actors : DEO

Preconditions : DEO must be logged onto the system before the use case begins.


49

Use Cases3.4 Post conditions : If the use case is successful, the subject information is added, updated, or deleted from the system, otherwise the system state is unchanged. 3.5 Basic flows :

The use case starts when DEO wishes to add, change, and/or delete subject information from the system. (i) The system requests DEO to specify the function he/she would like to perform i.e. • Add a subject • Update a subject • Delete a subject.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

50

Use Cases(ii) Once the DEO provides the required information, one of the sub flows is executed. If DEO selected “Add a subject” the “Add-a subject sub flow is executed. If DEO selected “Update-a subject” the “update-a- subject” sub flow is executed If DEO selected “Delete- a- subject”, the “Delete-a-subject” sub flow is executed. 3.5.1 Add a Subject (i) The System requests the DEO to enter the subject information. This includes : * Name of the subjectSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

51

Use Cases* Subject Code * Semester * Credit points (ii) Once DEO provides the requested information, the system generates and assigns a unique subject-id to the subject. The subject is added to the system. (iii) subject-id. The system provides the DEO with new


52

Use Cases3.5.2 Update a Subject(i) The system subject_id. requests the DEO to enter

(ii)

DEO enters the subject_id. The system retrieves and displays the subject information. DEO makes the changes. Record is updated.

(iii) (iv)


53

Use Cases3.5.3 Delete a Subject(i) (ii) Entry of subject_id. After this, system retrieves & displays subject information. * System prompts the DEO to confirm the deletion. * DEO verifies the deletion. * The system marks the subject record for deletion.


54

Use Cases3.6 Alternative Flow3.6.1 Subject not found If in any sub flows, subject-id not found, error message is displayed. The DEO may enter a different id or cancel the case ends here. 3.6.2 Update Cancelled If in the update a subject sub-flow, the data entry operator decides not to update the subject information, the update is cancelled and the basic flow is restarted at the begin.55


Use Cases3.6.3 Delete Cancellation If in delete-a-subject sub flow, the DEO decides not to delete subject, the delete is cancelled, and the basic flow is restarted from the beginning. 3.7 Special Requirements: None

3.8

Use Case-relationships NoneSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

56

Use Cases4. Maintain Result Details4.1 Introduction

This use case allows the DEO to maintain subject & marks information of each student. This includes adding and/or deleting subject and marks information from the system.

4.2

Actor DEO


57

Use Cases4.3 Pre ConditionsDEO must be logged onto the system.

4.4

Post ConditionsIf use case is successful ,marks information is added or deleted from the system. Otherwise, the system state is unchanged.


58

Use Cases4.5 Basic FlowThis use case starts, when the DEO wishes to add, update and/or delete marks from the system. (i) DEO to specify the function (ii) Once DEO provides the information one of the subflow is executed. * If DEO selected “Add Marks “, the Add marks subflow is executed. * If DEO selected “Update Marks”, the update marks subflow is executed. * If DEO selected “Delete Marks”, the delete marks subflow is executed.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

59

Use Cases4.5.1 Add Marks RecordsAdd marks information .This includes: a. Selecting a subject code. b. Selecting the student enrollment number. c. Entering internal/external marks for that subject code & enrollment number.


60

Use Cases(ii) If DEO tries to enter marks for the same combination of subject and enrollment number,the system gives a message that the marks have already been entered. (iii) Each record is assigned a unique result_id.

4.5.2 Delete Marks records1. DEO makes the following entries: a. Selecting subject for which marks have to be deleted. b. Selecting student enrollment number. c. Displays the record with id number. d. Verify the deletion. e. Delete the record.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

61

Use Cases4.5.2 Update Marks records1. The System requests DEO to enter the record_id. 2. DEO enters record_id. The system retrieves & displays the information. 3. DEO makes changes. 4. Record is updated.


62

Use CasesCompute Result (i) Once the marks are entered, result is computed for each student. (ii) If a student has scored more than 50% in a subject, the associated credit points are allotted to that student. (iii) The result is displayed with subject-code, marks & credit points. 4.6 Alternative Flow 4.6.1 Record not found If in update or delete marks sub flows, marks with specified id number do not exist, the system displays an error message. DEO can enter another id or cancel the operation.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

4.5.3

63

Use Cases4.6.2 Delete CancelledIf in Delete Marks, DEO decides not to delete marks, the delete is cancelled and basic flow is re-started at the beginning.

4.7 Special RequirementsNone

4.8 Use case relationshipsNoneSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

64

Use Cases5 View/Display result5.1 Introduction This use case allows the student/Teacher or anyone to view the result. The result can be viewed on the basis of course code and/or enrollment number. 5.2 Actors Administrator/DR, Teacher/Student 5.3 Pre Conditions None 5.4 Post Conditions If use case is successful, the marks information is displayed by the system. Otherwise, state is unchanged.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

65

Use Cases5.5 Basic FlowUse case begins when student, teacher or any other person wish to view the result.

Two ways -- Enrollment no. -- Course code


66

Use Cases(ii) After selection, one of the sub flow is executed. Course code Enrollment no. Sub flow is executed Sub flow is executed

5.5.1 View result enrollment number wise (i) User to enter enrollment number (ii) System retrieves the marks of all subjects with credit points (iii) Result is displayed.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

67

Use Cases5.6 Alternative Flow 5.6.1 Record not found Error message should be displayed.

5.7

Special Requirements None

5.8

Use Case relationships None


68

Use Cases6. Generate Report6.1 Introduction This use case allows the DR to generate result reports. Options are a. Course code wise b. Semester wise c. Enrollment Number wise 6.2 Actors DR 6.3 Pre-Conditions DR must logged on to the systemSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

69

Use Cases6.4 Post conditions If use case is successful, desired report is generated. Otherwise, the system state is unchanged. 6.5 Basic Flow The use case starts, when DR wish to generate reports. (i) DR selects option. (ii) System retrieves the information displays. (iii) DR takes printed reports.


70

Use Cases6.6 Alternative Flows 6.6.1 Record not found If not found, system generates appropriate message. The DR can select another option or cancel the operation. At this point, the use case ends. 6.7 Special Requirements None 6.8 Use case relationships None


71

Use Cases7. Maintain User Accounts7.1 Introduction

This use case allows the administrator to maintain user account. This includes adding, changing and deleting user account information from the system. 7.2 Actors Administrator 7.3 Pre-Conditions The administrator must be logged on to the system before the use case begins.


72

Use Cases7.4 Post-Conditions If the use case was successful, the user account information is added, updated, or deleted from the system. Otherwise, the system state is unchanged. 7.5 Basic Flow This use case starts when the Administrator wishes to add, change, and/or delete use account information from the system. (i) The system requests that the Administrator specify the function he/she would like to perform (either Add a User Account, Update a User Account, or Delete a User Account). (ii) Once the Administrator provides the requested information, one of the sub-flows is executedSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

73

Use Cases* If the Administrator selected “Add a User Account”, the Add a User Account sub flow is executed. * If the Administrator selected “Update a User Account”, the Update a User Account sub-flow is executed. * If the Administrator selected “Delete a User Account”, the Delete a User Account sub-flow is executed.22 7.5.1 Add a User Account 1. The system requests that the Administrator enters the user information. This includes: (a) User Name (b) User ID-should be unique for each user account (c) Password (d) Role .Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

74

Use Cases2. Once the Administrator provides the requested information, the user account information is added. 7.5.2 Update a User Account 1. The system requests that the Administrator enters the User ID. 2. The Administrator enters the User ID. The system retrieves and displays the user account information. 3. The Administrator makes the desired changes to the user account information. This includes any of the information specified in the Add a User Account sub-flow. 4. Once the Administrator updates the necessary information, the system updates the user account record with the updated information.


75

Use Cases7.5.3 Delete a User Account 1. The system requests that the Administrator enters the User ID. 2. The Administrator enters the User ID. The system retrieves and displays the user account information. 3. The system prompts the Administrator to confirm the deletion of the user account. 4. The Administrator confirms the deletion. 5. The system deletes the user account record.


76

Use Cases7.6 Alternative Flows 7.6.1 User Not Found If in the Update a User Account or Delete a User Account sub-flows, a user account with the specified User ID does not exist, the system displays an error message. The Administrator can then enter a different User ID or cancel the operation, at which point the use case ends. 7.6.2 Update Cancelled If in the Update a User Account sub-flow, the Administrator decides not to update the user account information, the update is cancelled and the Basic Flow is re-started at the beginning.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

77

Use Cases7.6.3 Delete Cancelled If in the Delete a User Account sub-flow, the Administrator decides not to delete the user account information, the delete is cancelled and the Basic Flow is re-started at the beginning. 7.7 Special Requirements None Use case relationships None

7.8


78

Use Cases8. Reset System8.1 Introduction This use case allows the allows the administrator to reset the system by deleting all existing information from the system . 8.2 Actors Administrator 8.3 Pre-Conditions The administrator must be logged on to the system before the use case begins.


79

Use Cases8.4 Post-Conditions If the use case was successful, all the existing information is deleted from the backend database of the system. Otherwise, the system state is unchanged. 8.5 Basic Flow This use case starts when the Administrator wishes to reset the system. i. The system requests the Administrator to confirm if he/she wants to delete all the existing information from the system. ii. Once the Administrator provides confirmation, the system deletes all the existing information from the backend database and displays an appropriate message.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

80

Use Cases8.6 Alternative Flows 8.6.1 Reset Cancelled

If in the Basic Flow, the Administrator decides not to delete the entire existing information, the reset is cancelled and the use case ends. 8.7 Special Requirements None 8.8 Use case relationships None


81

Requirements AnalysisWe analyze, refine and scrutinize requirements to make consistent & unambiguous requirements. StepsDraw the context Diagram

Develop prototype (optional)

Model the Requirements

Finalize the Requirements

Requirements Analysis StepsSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

82

Requirements AnalysisAdministrator Subject Information Entry Marks Entry Result Management System Marks Entry Operator

Student Information Entry

Student Information Reports generated

Mark sheet generated

Student performance Reports generated


83

Requirements AnalysisData Flow DiagramsDFD show the flow of data through the system. --All names should be unique -- It is not a flow chart -- Suppress logical decisions -- Defer error conditions & handling until the end of the analysis Symbol Name FunctionData Flow Connect process

Process

Perform some transformation of its input data to yield output data.84


Requirements AnalysisSymbol NameSource or sink Data Store

FunctionA source of system inputs or sink of system outputs A repository of data, the arrowhead indicate net input and net outputs to store

Leveling

DFD represent a system or software at any level of abstraction.

A level 0 DFD is called fundamental system model or context model represents entire software element as a single bubble with input and output data indicating by incoming & outgoing arrows.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

85

Requirements AnalysisI1

AI2 I1

O3

O3

I2


86

Data DictionariesDFD DD Data Dictionaries are simply repositories to store information about all data items defined in DFD. Includes : Name of data item Aliases (other names for items) Description/Purpose Related data items Range of values Data flows Data structure definition


87

Data DictionariesNotation x= a+b x={a/b} x=(a) x= y{a} x={a}z x=y{a}z Meaning x consists of data element a & b x consists of either a or b x consists of an optional data element a x consists of y or more occurrences x consists of z or fewer occurrences of a x consists of between y & z occurrences of a{Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

88

EntityEntity-Relationship DiagramsEntity-Relationship Diagrams It is a detailed logical representation of data for an organization and uses three main constructs.

Entities

Relationships

Attributes

Entities Fundamental thing about which data may be maintained. Each entity has its own identity. Entity Type is the description of all entities to which a common definition and common relationships and attributes apply.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

89

EntityEntity-Relationship DiagramsConsider an insurance company that offers both home and automobile insurance policies .These policies are offered to individuals and businesses. POLICYhome Automobile individual

CUSTOMERbusinesses

POLICY

CUSTOMER


90

EntityEntity-Relationship DiagramsRelationshipsA relationship is a reason for associating two entity types. Binary relationships involve two entity types A CUSTOMER is insured by a POLICY. A POLICY CLAIM is made against a POLICY. Relationships are represented by diamond notation in a ER diagram.Insured by POLICY

CUSTOMER

Made Against

Relationships added to ERD

POLICY CLAIM91


EntityEntity-Relationship DiagramsA training department is interested in tracking which training courses each of its employee has completed.

EMPLOYEE

completes

COURSE

Many-to Many relationship

Each employee may complete more than one course,and each course may be completed by more than one employee.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

92

EntityEntity-Relationship DiagramsDegree of relationshipIt is the number of entity types that participates in that relationship.

Unary

Binary

Ternary

Unary relationshipPersonIs Married to

One to One

Employee

Manages

One to manySoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

93

EntityEntity-Relationship DiagramsBinary RelationshipEMPLOYEE

Is assigned

PARKING PLACE

One to One

PRODUCT LINE

Contains

PRODUCT

One to many

STUDENT

Registers for

COURSE

Many to manySoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

94

EntityEntity-Relationship DiagramsTernary relationshipPart

Vendor

Ships

Ware House

Cardinalities and optionality Two entity types A,B, connected by a relationship. The cardinality of a relationship is the number of instances of entity B that can be associated with each instance of entity A

Movie

Is Stocked as

Video Tape


95

EntityEntity-Relationship DiagramsMinimum cardinality is the minimum number of instances of entity B that may be associated with each instance of entity A. Minimum no. of tapes available for a movie is zero.We say VIDEO TAPE is an optional participant in the is-stocked-as relationship.

MOVIE

Is Stocked As

VIDEO TAPE


96

EntityEntity-Relationship DiagramsAttributesEach entity type has a set of attributes associated with it. An attribute is a property or characteristic of an entity that is of interest to organization.

Attribute


97

EntityEntity-Relationship DiagramsA candidate key is an attribute or combination of attributes that uniquely identifies each instance of an entity type. Student_ID Candidate Key

If there are more candidate keys, one of the key may be chosen as the Identifier. It is used as unique characteristic for an entity type. Identifier


98

EntityEntity-Relationship DiagramsName Address

Student_ID

STUDENT

Phone_No

Vendors quote prices for several parts along with quantity of parts. Draw an E-R diagram.

Vendor

Quoteprice

Parts

quantity

price


99

Approaches to problem analysis1. List all inputs, outputs and functions. 2. List all functions and then list all inputs and outputs associated with each function.

Structured requirements definition (SRD)Step1 Define a user level DFD. Record the inputs and outputs for each individual in a DFD. Step2 Define a combined user level DFD. Step3 Define application level DFD. Step4 Define application level functions.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

100

Requirements DocumentationThis is the way of representing requirements in a consistent format SRS serves many purpose depending upon who is writing it.

---

written by customer written by developer

Serves as contract between customer & developer.


101

Requirements DocumentationNature of SRSBasic Issues • • • • • Functionality External Interfaces Performance Attributes Design constraints imposed on an Implementation


102

Requirements DocumentationSRS Should -- Correctly define all requirements -- not describe any design details -- not impose any additional constraints Characteristics of a good SRS An SRS Should be Correct Unambiguous Complete Consistent


103

Requirements DocumentationRanked for important and/or stability Verifiable Modifiable Traceable


104

Requirements DocumentationCorrectAn SRS is correct if and only if every requirement stated therein is one that the software shall meet.

UnambiguousAn SRS is unambiguous if and only if, every requirement stated therein has only one interpretation.

CompleteAn SRS is complete if and only if, it includes the following elements (i) All significant requirements, whether related to functionality, performance, design constraints, attributes or external interfaces.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

105

Requirements Documentation(ii) Responses to both valid & invalid inputs. (iii) Full Label and references to all figures, tables and diagrams in the SRS and definition of all terms and units of measure.

ConsistentAn SRS is consistent if and only if, no subset of individual requirements described in it conflict.

Ranked for importance and/or StabilityIf an identifier is attached to every requirement to indicate either the importance or stability of that particular requirement.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

106

Requirements DocumentationVerifiableAn SRS is verifiable, if and only if, every requirement stated therein is verifiable.

ModifiableAn SRS is modifiable, if and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining structure and style.

TraceableAn SRS is traceable, if the origin of each of the requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

107

Requirements DocumentationOrganization of the SRSIEEE has published guidelines and standards to organize an SRS. First two sections are same. The specific tailoring occurs in section-3. 1. Introduction 1.1 1.2 1.3 1.4 1.5

Purpose Scope Definition, Acronyms and abbreviations References Overview


108

Requirements Documentation2. The Overall Description 2.1 Product Perspective 2.1.1 System Interfaces 2.1.2 Interfaces 2.1.3 Hardware Interfaces 2.1.4 Software Interfaces 2.1.5 Communication Interfaces 2.1.6 Memory Constraints 2.1.7 Operations 2.1.8 Site Adaptation Requirements


109

Requirements Documentation2.2 2.3 2.4 2.5 2.6 Product Functions User Characteristics Constraints Assumptions for dependencies Apportioning of requirements

3. Specific Requirements 3.1 External Interfaces 3.2 Functions 3.3 Performance requirements 3.4 Logical database requirements 3.5 Design Constraints 3.6 Software System attributes 3.7 Organization of specific requirements 3.8 Additional Comments.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

110

Requirements ValidationCheck the document for:Completeness & consistency Conformance to standards Requirements conflicts Technical errors Ambiguous requirements


111

Requirements Validation

SRS document List of problems Organizational standards Validation process

Organizational knowledge

Approved actions


112

Requirements Review ProcessPlan review Plan review Distribute Distribute SRS SRS documents documents Read Read documents documents

Organize Organize review review

Revise Revise document document

Follow up Follow up actions actions113


Requirements ValidationProblem actions • Requirements clarification • Missing information • find this information from stakeholders • Requirements conflicts • Stakeholders must negotiate to resolve this conflict • Unrealistic requirements • Stakeholders must be consulted • Security issues • Review the system in accordance to security standards


114

Review ChecklistsRedundancy Completeness Ambiguity Consistency Organization Conformance Traceability


115

PrototypingValidation prototype should be reasonably complete & efficient & should be used as the required system.


116

Requirements Management• Process of understanding and controlling changes to system requirements. ENDURING & VOLATILE REQUIREMENTS o Enduring requirements: They are core requirements & are related to main activity of the organization. Example: issue/return of a book, cataloging etc. o Volatile requirements: likely to change during software development lifer cycle or after delivery of the product


117

Requirements Management Planning• Very critical. • Important for the success of any project.


118

Requirements Change Management• Allocating adequate resources • Analysis of requirements • Documenting requirements • Requirements traceability • Establishing team communication • Establishment of baseline


119

Download from

Q:\IRM\PRIVATE\INITIATIATI\QA\QAPLAN\SRSPLAN.DOC


120

Multiple Choice QuestionsNote. Choose the most appropriate answer of the following questions.

3.1

Which one is not a step of requirement engineering? (a) Requirements elicitation (b) Requirements analysis (c) Requirements design (d) Requirements documentation

3.2

Requirements elicitation means (a) Gathering of requirements (b) Capturing of requirements (c) Understanding of requirements (d) All of the aboveSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

121

Multiple Choice Questions3.3 SRS stands for (a) Software requirements specification (b) System requirements specification (c) Systematic requirements specifications (d) None of the above 3.4 SRS document is for (a) “What” of a system? (b) How to design the system? (c) Costing and scheduling of a system (d) System’s requirement.


122

Multiple Choice Questions3.5 Requirements review process is carried out to (a) Spend time in requirements gathering (b) Improve the quality of SRS (c) Document the requirements (d) None of the above 3.6 Which one of the statements is not correct during requirements engineering? (a) (b) (c) (d) Requirements are difficult to uncover Requirements are subject to change Requirements should be consistent Requirements are always precisely known.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

123

Multiple Choice Questions3.7 Which one is not a type of requirements? (a) Known requirements (b) Unknown requirements (c) Undreamt requirements (d) Complex requirements 3.8 Which one is not a requirements elicitation technique? (a) Interviews (b) The use case approach (c) FAST (d) Data flow diagram.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

124

Multiple Choice Questions3.9 FAST stands for (a) Functional Application Specification Technique (b) Fast Application Specification Technique (c) Facilitated Application Specification Technique (d) None of the above 3.10 (a) (b) (c) (d) QFD in requirement engineering stands for

Quality function design Quality factor design Quality function development Quality function deployment


125

Multiple Choice Questions3.11 Which is not a type of requirements under quality function deployment (a) Normal requirements (b) Abnormal requirements (c) Expected requirements (d) Exciting requirements 3.12 Use case approach was developed by (a) I. Jacobson and others (b) J.D. Musa and others (c) B. Littlewood (d) None of the aboveSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

126

Multiple Choice Questions3.13 Context diagram explains (a) The overview of the system (b) The internal view of the system (c) The entities of the system (d) None of the above 3.14 DFD stands for (a) (b) (c) (d) Data Flow design Descriptive functional design Data flow diagram None of the above


127

Multiple Choice Questions3.15 Level-O DFD is similar to (a) Use case diagram (b) Context diagram (c) System diagram (d) None of the above 3.16 ERD stands for (a) Entity relationship diagram (b) Exit related diagram (c) Entity relationship design (d) Exit related designSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

128

Multiple Choice Questions3.17 Which is not a characteristic of a good SRS? (a) (b) (c) (d) 3.18 Correct Complete Consistent Brief

Outcome of requirements specification phase is (a) (b) (c) (d) Design Document Software requirements specification Test Document None of the above


129

Multiple Choice Questions3.19 The basic concepts of ER model are: (a) Entity and relationship (b) Relationships and keys (c) Entity, effects and relationship (d) Entity, relationship and attribute 3.20 The DFD depicts (a) (b) (c) (d) Flow of data Flow of control Both (a) and (b) None of the above


130

Multiple Choice Questions3.21 Product features are related to: (a) Functional requirements (b) Non functional requirements (c) Interface requirement (d) None of the above 3.22 Which one is a quality attribute? (a) (b) (c) (d) Reliability Availability Security All of the above


131

Multiple Choice Questions3.23 IEEE standard for SRS is: (a) IEEE Standard 837-1998 (b) IEEE Standard 830-1998 (c) IEEE Standard 832-1998 (d) IEEE Standard 839-1998 3.24 Which one is not a functional requirement? (a) Efficiency (b) Reliability (c) Product features (d) Stability


132

Multiple Choice Questions3.23 APIs stand for: (a) Application performance interfaces (b) Application programming interfaces (c) Application programming integration (d) Application performance integration


133

Exercises3.1 Discuss the significance and use of requirement engineering. What are the problems in the formulation of requirements? 3.2 Requirements analysis is unquestionably the most communication intensive step in the software engineering process. Why does the communication path frequently break down ? 3.3 What are crucial process steps of requirement engineering ? Discuss with the help of a diagram. 3.4 Discuss the present state of practices in requirement engineering. Suggest few steps to improve the present state of practice. 3.5 Explain the importance of requirements. How many types of requirements are possible and why ? 3.6 Describe the various steps of requirements engineering. Is it essential to follow these steps ? 3.7 What do you understand with the term “requirements elicitation” ? Discuss any two techniques in detail. 3.8 List out requirements elicitation techniques. Which one is most popular and why ?Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

134

Exercises3.9 Describe facilitated application specification technique (FAST) and compare this with brainstorming sessions. 3.10 Discuss quality function deployment technique of requirements elicitation. Why an importance or value factor is associated with every requirement ? 3.11. Explain the use case approach of requirements elicitation. What are use-case guidelines ? 3.12. What are components of a use case diagram. Explain their usage with the help of an example. 3.13. Consider the problem of library management system and design the following: (i) Problem statement (ii) Use case diagram (iii) Use cases.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

135

Exercises3.14. Consider the problem of railway reservation system and design the following: (i) Problem statement (ii) Use case diagram (iii) Use cases. 3.15. Explain why a many to many relationship is to be modeled as an associative entity ? 3.16. What are the linkages between data flow and E–R diagrams ? 3.17. What is the degree of a relationship ? Give an example of each of the relationship degree. 3.18. Explain the relationship between minimum cardinality and optional and mandatory participation. 3.19. An airline reservation is an association between a passenger, a flight, and a seat. Select a few pertinent attributes for each of these entity types and represent a reservation in an E–R diagram.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

136

Exercises3.20. A department of computer science has usual resources and usual users for these resources. A software is to be developed so that resources are assigned without conflict. Draw a DFD specifying the above system. 3.21. Draw a DFD for result preparation automation system of B. Tech. courses (or MCA program) of any university. Clearly describe the working of the system. Also mention all assumptions made by you. 3.22. Write short notes on (i) Data flow diagram (ii) Data dictionary. 3.23. Draw a DFD for borrowing a book in a library which is explained below: “A borrower can borrow a book if it is available else he/she can reserve for the book if he/she so wishes. He/she can borrow a maximum of three books”. 3.24. Draw the E–R diagram for a hotel reception desk management. Explain why, for large software systems development, is it recommended that prototypes should be “throw-away” prototype ?Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

137

Exercises3.26. Discuss the significance of using prototyping for reusable components and explain the problems,which may arise in this situation. 3.27. Suppose a user is satisfied with the performance of a prototype. If he/she is interested to buy this for actual work, what should be the response of a developer ? 3.28. Comment on the statement: “The term throw-away prototype is inappropriate in that these prototypes expand and enhance the knowledge base that is retained and incorporated in the final prototype; therefore they are not disposed of or thrown away at all.” 3.29. Which of the following statements are ambiguous ? Explain why. (a) The system shall exhibit good response time. (b) The system shall be menu driven. (c) There shall exist twenty-five buttons on the control panel, numbered PF1 to PF25. (d) The software size shall not exceed 128K of RAM.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

138

Exercises3.30. Are there other characteristics of an SRS (besides listed in section 3.4.2) that are desirable ? List a few and describe why ? 3.31. What is software requirements specification (SRS) ? List out the advantages of SRS standards. Why is SRS known as the black box specification of a system ? 3.32. State the model of a data dictionary and its contents. What are its advantages ? 3.33. List five desirable characteristics of a good SRS document. Discuss the relative advantages of formal requirement specifications. List the important issues, which an SRS must address. 3.34. Construct an example of an inconsistent (incomplete) SRS. 3.35. Discuss the organization of a SRS. List out some important issues of this organization.


139

Exercises3.36. Discuss the difference between the following: (a) Functional & nonfunctional requirements (b) User & system requirements


140


1

Software Project PlanningAfter the finalization of SRS, we would like to estimate size, cost and development time of the project. Also, in many cases, customer may like to know the cost and development time even prior to finalization of the SRS.


2

Software Project PlanningIn order to conduct a successful software project, we must understand:Scope of work to be done The risk to be incurred The resources required The task to be accomplished The cost to be expended The schedule to be followedSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

3

Software Project PlanningSoftware planning begins before technical work starts, continues as the software evolves from concept to reality, and culminates only when the software is retired.Size estimation

Cost estimation Resources requirements

Development time

Fig. 1: Activities during Software Project Planning

Project scheduling4


Software Project PlanningSize EstimationLines of Code (LOC) If LOC is simply a count of the number of lines then figure shown below contains 18 LOC . When comments and blank lines are ignored, the program in figure 2 shown below contains 17 LOC. Fig. 2: Function for sorting an array1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. int. sort (int x[ ], int n) { int i, j, save, im1; /*This function sorts array x in ascending order */ If (n<2) return 1; for (i=2; i<=n; i++) { im1=i-1; for (j=1; j<=im; j++) if (x[i] < x[j]) { Save = x[i]; x[i] = x[j]; x[j] = save; } } return 0; } 5


Software Project PlanningGrowth of Lines of Code (LOC)2,500,000

Total LOC ("wc -l") -- development releases2,000,000

Total LOC ("wc -l") -- stable releases Total LOC uncommented -- development releases Total LOC uncommented -- stable releases

Total LOC

1,500,000

1,000,000

500,000

0 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 2001


6

Software Project PlanningFurthermore, if the main interest is the size of the program for specific functionality, it may be reasonable to include executable statements. The only executable statements in figure shown above are in lines 5-17 leading to a count of 13. The differences in the counts are 18 to 17 to 13. One can easily see the potential for major discrepancies for large programs with many comments or programs written in language that allow a large number of descriptive but non-executable statement. Conte has defined lines of code as:Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

7

Software Project Planning“A line of code is any line of program text that is not a comment or blank line, regardless of the number of statements or fragments of statements on the line. This specifically includes all lines containing program header, declaration, and executable and non-executable statements”. This is the predominant definition for lines of code used by researchers. By this definition, figure shown above has 17 LOC.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

8

Software Project PlanningFunction Count

Alan Albrecht while working for IBM, recognized the problem in size measurement in the 1970s, and developed a technique (which he called Function Point Analysis), which appeared to be a solution to the size measurement problem.


9

Software Project PlanningThe principle of Albrecht’s function point analysis (FPA) is that a system is decomposed into functional units.Inputs Outputs Enquiries Internal logical files External interface files : : : : : information entering the system information leaving the system requests for instant access to information information held within the system information held by other system that is used by the system being analyzed.10


Software Project PlanningThe FPA functional units are shown in figure given below:User

Inquiries

Inputs User Outputs

ILF

Other applicationsEIF

System

ILF: Internal logical files EIF: External interfaces

Fig. 3: FPAs functional units SystemSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

11

Software Project PlanningThe five functional units are divided in two categories: (i) Data function typesInternal Logical Files (ILF): A user identifiable group of logical related data or control information maintained within the system. External Interface files (EIF): A user identifiable group of logically related data or control information referenced by the system, but maintained within another system. This means that EIF counted for one system, may be an ILF in another system.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

12

Software Project Planning(ii) Transactional function typesExternal Input (EI): An EI processes data or control information that comes from outside the system. The EI is an elementary process, which is the smallest unit of activity that is meaningful to the end user in the business. External Output (EO): An EO is an elementary process that generate data or control information to be sent outside the system. External Inquiry (EQ): An EQ is an elementary process that is made up to an input-output combination that results in data retrieval.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

13

Software Project PlanningSpecial features Function point approach is independent of the language, tools, or methodologies used for implementation; i.e. they do not take into consideration programming languages, data base management systems, processing hardware or any other data base technology. Function points can be estimated from requirement specification or design specification, thus making it possible to estimate development efforts in early phases of development.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

14

Software Project PlanningFunction points are directly linked to the statement of requirements; any change of requirements can easily be followed by a re-estimate. Function points are based on the system user’s external view of the system, non-technical users of the software system have a better understanding of what function points are measuring.


15

Software Project PlanningCounting function pointsFunctional Units External Inputs (EI) External Output (EO) External Inquiries (EQ) External logical files (ILF) External Interface files (EIF) Weighting factors Low Average High 3 4 6 4 5 7 3 4 6 7 10 15 5 7 10

Table 1 : Functional units with weighting factorsSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

16

Software Project PlanningTable 2: UFP calculation tableFunctional Units External Inputs (EIs) External Outputs (EOs) External Inquiries (EQs) External logical Files (ILFs) External Interface Files (EIFs)Count Complexity Low x 3 Average x 4 High x 6 Low x 4 Average x 5 High x 7 Low x 3 Average x 4 High x 6 Low x 7 Average x 10 High x 15 Low x 5 Average x 7 High x 10 Complexity Totals = = = = = = = = = = = = = = =

Functional Unit Totals

Total Unadjusted Function Point CountSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

17

Software Project PlanningThe weighting factors are identified for all functional units and multiplied with the functional units accordingly. The procedure for the calculation of Unadjusted Function Point (UFP) is given in table shown above.


18

Software Project PlanningThe procedure for the calculation of UFP in mathematical form is given below:

UFP = ∑∑ Z ij wiji =1 J =1Where i indicate the row and j indicates the column of Table 1Wij : It is the entry of the ith row and jth column of the table 1 Zij : It is the count of the number of functional units of Type i that have been classified as having the complexity corresponding to column j.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

5

3

19

Software Project PlanningOrganizations that use function point methods develop a criterion for determining whether a particular entry is Low, Average or High. Nonetheless, the determination of complexity is somewhat subjective. FP = UFP * CAF Where CAF is complexity adjustment factor and is equal to [0.65 + 0.01 x ΣFi]. The Fi (i=1 to 14) are the degree of influence and are based on responses to questions noted in table 3.�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh

�ingh, Copyright © New Ag

e International Publishers, 2007

20

�oftware Project PlanningTable 3 : Computing function points.Rate each factor on a scale of 0 to 5. 0 1 No Incidental Influence Number of factors considered ( Fi ) 2 Moderate 3 Average 4

�ignificant 5 Essential

1. Does the system require reliable backup and recovery ? 2. Is data communication required ? 3. Are there distributed processing functions ? 4. Is performance critical ? 5. Will the system run in an existing heavily utilized operational environment ? 6. Does the system require on line data entry ? 7. Does the on line data entry require the input transaction to be built over multiple screens or operations ? 8. Are the master files updated on line ? 9. Is the inputs, outputs, files, or inquiries complex ? 10. Is the internal processing complex ? 11. Is the code designed to be reusable ? 12. Are conversion and installation included in the design ? 13. Is the system designed for multiple installations in different organizations ? 14. Is the application designed to facilitate change and ease of use by the user ?�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



21

�oftware Project PlanningFunctions points may compute the following important metrics: Productivity Quality Cost Documentation = = = = FP / persons-months Defects / FP Rupees / FP Pages of documentation per FP

These metrics are controversial and are not universally acceptable. There are standards issued by the International Functions Point User Group (IFPUG, covering the Albrecht method) and the United Kingdom Function Point User Group (UFPGU, covering the MK11 method). An I

�O standard for function point method is also being

developed.�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



22

�oftware Project PlanningExample: 4.1Consider a project with the following functional units:Number of user inputs Number of user outputs Number of user enquiries Number of user files Number of external interfaces = 50 = 40 = 35 = 06 = 04

Assume all complexity adjustment factors and weighting factors are average. Compute the function points for the project.�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



23

�oftware Project Planning�olution We know5 3

UFP = ∑∑ Z ij wiji =1 J =1

UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7 = 200 + 200 + 140 + 60 + 28 = 628 CAF = (0.65 + 0.01 ΣFi) = (0.65 + 0.01 (14 x 3)) = 0.65 + 0.42 = 1.07 FP = UFP x CAF = 628 x 1.07 = 672�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



24

�oftware Project PlanningExample:4.2 An application has the following: 10 low external inputs, 12 high external outputs, 20 low internal logical files, 15 high external interface files, 12 average external inquiries, and a value of complexity adjustment factor of 1.10. What are the unadjusted and adjusted function point counts ?�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



25

�oftware Project Planning�olution Unadjusted function point counts may be calculated using as:

UFP = ∑∑ Z ij wiji =1 J =1

5

3

FP

= 10 x 3 + 12 x 7 + 20 x 7 + 15 + 10 + 12 x 4 = 30 + 84 +140 + 150 + 48 = 452 = UFP x CAF = 452 x 1.10 = 497.2.�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



26

�oftware Project PlanningExample: 4.3 Consider a project with the following parameters. (i) External Inputs: (a) 10 with low complexity (b)15 with average complexity (c) 17 with high complexity (ii) External Outputs: (a) 6 with low complexity (b)13 with high complexity (iii) External Inquiries: (a) 3 with low complexity (b) 4 with average complexity (c) 2 high complexity�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



27

�oftware Project Planning(iv) Internal logical files: (a) 2 with average complexity (b)1 with high complexity (v) External Interface files: (a) 9 with low complexity In addition to above, system requires i.

�ignificant data communication ii. Performance is very cri

tical iii. Designed code may be moderately reusable iv. �ystem is not designed f

or multiple installation in different organizations. Other complexity adjustment factors are treated as average. Compute the function points for the project.�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



28

�oftware Project Planning�olution: Unadjusted function points may be counted using table 2Functional Units External Inputs (EIs) External Outputs (EOs) External Inquiries (EQs) External logical Files (ILFs) External Interface Files (EIFs)Count10 15 17 6 0 13 3 4 2 0 2 1 9 0 0

Complexity Low x 3 Average x 4 High x 6 Low x 4 Average x 5 High x 7 Low x 3 Average x 4 High x 6 Low x 7 Average x 10 High x 15 Low x 5 Average x 7 High x 10 = = = = = = = = = = = = = = =

Complexity Totals30 60 102 24 0 91 9 16 12 0 20 15 45 0 0

Functional Unit Totals

192

115

37

35

45 424

Total Unadjusted Function Point Count�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



29

�oftware Project Planning

∑ F = 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41i i =1

14

CAF = (0.65 + 0.01 x ΣFi) = (0.65 + 0.01 x 41) = 1.06 FP = UFP x CAF = 424 x 1.06 = 449.44

Hence

FP = 449�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



30

�oftware Project PlanningRelative Cost of

�oftware Phases�

oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh �ingh, Copyright © New Ag


31

�oftware Project PlanningCost to Detect and Fix FaultsRelative Cost to detect and correct fault

200 180 160 140 120 100 80 60 40 20 0 Req Des I nt�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



Cost

32

�oftware Project PlanningCost Estimation A number of estimation techniques have been developed and are having following attributes in common :Project scope must be established in advance

�oftware metrics are used as a basi

s from which estimates are made The project is broken into small pieces which are estimated individually

To achieve reliable cost and schedule estimates, a number of options arise:Delay estimation until late in project Use simple decomposition techniques to generate project cost and schedule estimates Develop empirical models for estimation Acquire one or more automated estimation tools�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



33

�oftware Project PlanningMODEL

��tatic,

�ingle Variable Models�

tatic, Multivariable Models�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



34

�oftware Project Planning�tatic,

�ingle Variable Models

Methods using this model use an equation to estimate the desired values such as cost, time, effort, etc. They all depend on the same variable used as predictor (say, size). An example of the most common equations is :

C = a LbE = 1.4 L0.93 DOC = 30.4 L0.90 D = 4.6 L0.26

(i)

C is the cost, L is the size and a,b are constants

Effort (E in Person-months), documentation (DOC, in number of pages) and duration (D, in months) are calculated from the number of lines of code (L, in thousands of lines) used as a predictor.�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



35

�oftware Project Planning�tatic, Multivariable ModelsThese models are often based on equation (i), they actually depend on several variables representing various aspects of the software development environment, for example method used, user participation, customer oriented changes, memory constraints, etc.

E D

= 5.2 L0.91 = 4.1 L0.36

The productivity index uses 29 variables which are found to be highly correlated to productivity as follows:

Ι = ∑ Wi X ii =1Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age �nternational Publishers, 200729

36

Software Project PlanningExample: 4.4 Compare the Walston-Felix model with the SEL model on a software development expected to involve 8 person-years of effort. (a)Calculate the number of lines of source code that can be produced. (b)Calculate the duration of the development. (c)Calculate the productivity in LOC/PY (d)Calculate the average manning

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age �nternational Publishers, 200737

Software Project PlanningSolution The amount of manpower involved = 8 PY = 96 person-months (a) Number of lines of source code can be obtained by reversing equation to give: L = (E/a)1/b Then L(SEL) = (96/1.4)1/0.93 = 94264 LOC L(SEL) = (96/5.2)1/0.91 = 24632 LOC.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age �nternational Publishers, 200738

Software Project Planning(b) Duration in months can be calculated by means of equation D(SEL) = 4.6 (L)0.26 = 4.6 (94.264)0.26 = 15 months D(W-F) = 4.1 L0.36 = 4.1(24.632)0.36 = 13 months (c) Productivity is the lines of code produced per person/month (year)

94264 P( SEL) = = 11783 LOC / Person − Years 8 24632 P(W − F ) = = 3079 LOC / Person − Years 8Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

39

Software Project Planning(d) Average manning is the average number of persons required per month in the project.

96 P − M M ( SEL ) = = 6.4 Persons 15 M 96 P − M M (W − F ) = = 7.4 Persons 13 M


40

Software Project PlanningThe Constructive Cost Model (COCOMO)Constructive Cost model (COCOMO)

Basic

Intermediate

Detailed

Model proposed by B. W. Boehm’s through his book Software Engineering Economics in 1981Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

41

Software Project PlanningCOCOMO applied to

Organic mode

Semidetached mode

Embedded mode


42

Software Project PlanningMode Project size Nature of Project Innovation Deadline of the project Not tight Development Environment Familiar & In house Organic Typically 2�50 KLOC Small size project, experienced developers in the familiar environment. For example, pay roll, inventory projects etc. Little

Semi detached

Typically 50�300 KLOCMedium size project, Medium size team, Average previous experience on similar project. For example: Utility systems like compilers, database systems, editors etc. Large project, Real time systems, Complex interfaces, Very little previous experience. For example: ATMs, Air Traffic Control etc.

Medium

Medium

Medium

Embedded Typically over 300 KLOC

Significant

Tight

Complex Hardware/ customer Interfaces required

Table 4: The comparison of three COCOMO modesSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

43

Software Project PlanningBasic Model Basic COCOMO model takes the form

E = ab ( KLOC )

bb

D = cb ( E )

db

where E is effort applied in Person�Months, and D is the development time in months. The coefficients ab, bb, cb and db are given in table 4 (a).Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

44

Software Project Planningab2.4 3.0 3.6

Software Project Organic Semidetached Embedded

bb1.05 1.12 1.20

cb2.5 2.5 2.5

db0.38 0.35 0.32

Table 4(a): Basic COCOMO coefficients


45

Software Project PlanningWhen effort and development time are known, the average staff size to complete the project may be calculated as:

E Average staff size ( SS ) = Persons DWhen project size is known, the productivity level may be calculated as:

KLOC Productivity ( P ) = KLOC / PM E


46

Software Project PlanningExample: 4.5

Suppose that a project was estimated to be 400 KLOC. Calculate the effort and development time for each of the three modes i.e., organic, semidetached and embedded.


47

Software Project PlanningSolution The basic COCOMO equation take the form:

E = ab ( KLOC ) bb D = cb ( KLOC )(i) Organic mode E = 2.4(400)1.05 = 1295.31 PM D = 2.5(1295.31)0.38 = 38.07 PMdb

Estimated size of the project = 400 KLOC


48

Software Project Planning(ii) Semidetached mode E = 3.0(400)1.12 = 2462.79 PM D = 2.5(2462.79)0.35 = 38.45 PM (iii) Embedded mode E = 3.6(400)1.20 = 4772.81 PM D = 2.5(4772.8)0.32 = 38 PM


49

Software Project PlanningExample: 4.6 A project size of 200 KLOC is to be developed. Software development team has average experience on similar type of projects. The project schedule is not very tight. Calculate the effort, development time, average staff size and productivity of the project.


50

Software Project PlanningSolution The semi�detached mode is the most appropriate mode; keeping in view the size, schedule and experience of the development team. Hence E = 3.0(200)1.12 = 1133.12 PM D = 2.5(1133.12)0.35 = 29.3 PM

E Average staff size ( SS ) = Persons D1133.12 = = 38.67 Persons 29.3Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

51

Software Project PlanningKLOC 200 Productivity = = = 0.1765 KLOC / PM E 1133.12

P = 176 LOC / PM


52

Software Project PlanningIntermediate Model Cost drivers (i) Product Attributes Required s/w reliability Size of application database Complexity of the product (ii) Hardware Attributes Run time performance constraints Memory constraints Virtual machine volatility Turnaround timeSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

53

Software Project Planning(iii) Personal Attributes Analyst capability Programmer capability Application experience Virtual m/c experience Programming language experience (iv) Project Attributes Modern programming practices Use of software tools Required development ScheduleSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

54

Software Project PlanningMultipliers of different cost driversCost Drivers Very low Product Attributes RELY DATA CPLX Computer Attributes TIME STOR VIRT TURN��RATINGS Low Nominal High Very high Extra high

0.75��0.88 0.94 0.85

1.00 1.00 1.00

1.15 1.08 1.15

1.40 1.16 1.30��0.70

1.65

1.00 1.00 1.00 1.00

1.11 1.06 1.15 1.07

1.30 1.21 1.30 1.15

1.66 1.56��550.87 0.87


Software Project PlanningCost Drivers Very low Personnel Attributes ACAP AEXP PCAP VEXP LEXP Project Attributes MODP TOOL SCED 1.24 1.24 1.23 1.10 1.10 1.08 1.00 1.00 1.00 0.91 0.91 1.04 0.82 0.83 1.10��RATINGS Low Nominal High Very high Extra high

1.46 1.29 1.42 1.21 1.14

1.19 1.13 1.17 1.10 1.07

1.00 1.00 1.00 1.00 1.00

0.86 0.91 0.86 0.90 0.95

0.71 0.82 0.70��Table 5: Multiplier values for effort calculationsSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

56

Software Project PlanningIntermediate COCOMO equations

E = ai ( KLOC ) bi * EAF D = ci ( E ) d iProject Organic Semidetached Embedded ai 3.2 3.0 2.8 bi 1.05 1.12 1.20 ci 2.5 2.5 2.5 di 0.38 0.35 0.32

Table 6: Coefficients for intermediate COCOMOSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

57

Software Project PlanningDetailed COCOMO Model Detailed COCOMO

Phase�Sensitive effort multipliers Cost drivers design & testThree level product hierarchy Modules subsystem System level

Manpower allocation for each phaseSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

58

Software Project PlanningDevelopment Phase Plan / Requirements EFFORT : 6% to 8% 10% to 40%

DEVELOPMENT TIME : % depend on mode & size


59

Software Project PlanningDesignEffort Time : : 16% to 18% 19% to 38%

ProgrammingEffort Time : : 48% to 68% 24% to 64%

Integration & TestEffort Time : : 16% to 34% 18% to 34%60


Software Project PlanningPrinciple of the effort estimate Size equivalentAs the software might be partly developed from software already existing (that is, re�usable code), a full development is not always required. In such cases, the parts of design document (DD%), code (C%) and integration (I%) to be modified are estimated. Then, an adjustment factor, A, is calculated by means of the following equation. A = 0.4 DD + 0.3 C + 0.3 I The size equivalent is obtained by S (equivalent) = (S x A) / 100

Ep = µ pE Dp = τ p DSof

�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh

� © New Ag

e In�erna

�ional Publishers, 2007

61

Sof�ware Projec

� Planning

Lifecycle Phase Values ofMode & Code Size Organic Small S≈2 Organic medium S≈32 Semide

�ached medium S≈32 Semide�

ached large S≈128 Embedded large S≈128 Embedded ex�ra large S≈320 Plan & Requiremen

�s

0.06 0.06 0.07 0.07 0.08

µpDe�ailed Design 0.26 0.24 0.25 0.24 0.25 Module Code & Tes

� 0.42 0.38 0.33 0.31

0.26 In�egra

�ion & Tes

� 0.16 0.22 0.25 0.28 0.31

Sys�em Design 0.16 0.16 0.17 0.17 0.18

0.08

0.18

0.24

0.24

0.34

Table 7 : Effor� and schedule frac

�ions occurring in each phase of

�he lifecycle

Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh

� © New Ag

e In�erna


62

Sof�ware Projec

� Planning

Lifecycle Phase Values ofMode & Code Size Organic Small S≈2 Organic medium S≈32 Semide

�ached medium S≈32 Semide�

ached large S≈128 Embedded large S≈128 Embedded ex�ra large S≈320 Plan & Requiremen

�s

0.10 0.12 0.20 0.22 0.36

τpDe�ailed Design 0.24 0.21 0.21 0.19 0.18 Module Code & Tes

� 0.39 0.34 0.27 0.25

0.18 In�egra

�ion & Tes

� 0.18 0.26 0.26 0.29 0.28

Sys�em Design 0.19 0.19 0.26 0.27 0.36

0.40

0.38

0.16

0.16

0.30

Table 7 : Effor� and schedule frac

�ions occurring in each phase of

�he lifecycle


� © New Ag

e In�erna


63

Sof�ware Projec

� Planning

Dis�ribu

�ion of sof

�ware life cycle: 1. Requiremen

� and produc

� design (a) Plans

and requiremen�s (b)Sys

�em design De

�ailed Design (a) De

�ailed design Code & Un

i� �es� (a) Module code &

�es� In

�egra

�e and Tes

� (a) In

�egra

�e & Tes

�Sof


� © New Ag

e In�erna


2. 3. 4.

64

Sof�ware Projec

� Planning

Example: 4.7 A new projec� wi

�h es

�ima

�ed 400 KLOC embedded sys

�em has

�o be dev

eloped. Projec� manager has a choice of hiring from

�wo pools of developers: Ver

y highly capable wi�h very li

��le experience in

�he programming language being u

sed Or Developers of low quali�y bu

� a lo

� of experience wi

�h �he programming la

nguage. Wha� is

�he impac

� of hiring all developers from one or

�he o

�her pool ?


� © New Ag

e In�erna


65

Sof�ware Projec

� Planning

Solu�ion This is

�he case of embedded mode and model is in

�ermedia

�e COCOMO. Hen

ce

E = ai ( KLOC )

di

= 2.8 (400)1.20 = 3712 PM Case I: Developers are very highly capable wi�h very l

i��

le experience in �he programming being used. EAF E D = 0.82 x 1.14 = 0.9348 =

3712 x .9348 = 3470 PM = 2.5 (3470)0.32 = 33.9 MSof


� © New Ag

e In�erna


66

Sof�ware Projec

� Planning

Case II: Developers are of low quali�y bu

� lo

� of experience wi

�h �he programmin

g language being used. EAF E D = 1.29 x 0.95 = 1.22 = 3712 x 1.22 = 4528 PM = 2.5 (4528)0.32 = 36.9 M

Case II requires more effor� and

�ime. Hence, low quali

�y developers wi

�h lo

� of

programming language experience could no� ma

�ch wi

�h �he performance of very hi

ghly capable developers wi�h very li

��er experience.


� © New Ag

e In�erna


67

Sof�ware Projec

� Planning

Example: 4.8 Consider a projec� �o develop a full screen edi

�or. The major compo

nen�s iden

�ified are: I. Screen edi

� II. Command Language In

�erpre

�er III. File

Inpu� & Ou

�pu� IV. Cursor Movemen

� V. Screen Movemen

� The size of

�hese are es

�i

ma�ed

�o be 4k, 2k, 1k, 2k and 3k delivered source code lines. Use COCOMO

�o de

�ermine 1. Overall cos

� and schedule es

�ima

�es (assume values for differen

� cos

�

drivers, wi�h a

� leas

� �hree of

�hem being differen

� from 1.0) 2. Cos

� & Schedul

e es�ima

�es for differen

� phases.


� © New Ag

e In�erna


68

Sof�ware Projec

� Planning

Solu�ion

Size of five modules are: Screen edi� Command language in

�erpre

�er File inpu

� an

d ou�pu� Cursor movemen

� Screen movemen

� To

�al = 4 KLOC = 2 KLOC = 1 KLOC = 2 KL

OC = 3 KLOC = 12 KLOC69


� © New Ag

e In�erna


Sof�ware Projec

� Planning

Le� us assume

�ha� significan

� cos

� drivers are

i. Required sof�ware reliabili

�y is high, i.e.,1.15

ii. Produc� complexi

�y is high, i.e.,1.15 iii. Analys

� capabili

�y is high, i.e.,

0.86 iv. Programming language experience is low,i.e.,1.07 v. All o�her drivers a

re nominal EAF = 1.15x1.15x0.86x1.07 = 1.2169


� © New Ag

e In�erna


70

Sof�ware Projec

� Planning

(a) The ini�ial effor

� es

�ima

�e for

�he projec

� is ob

�ained from

�he following e

qua�ion E = ai (KLOC)bi x EAF = 3.2(12)1.05 x 1.2169 = 52.91 PM Developmen

� �ime

D = Ci(E)di = 2.5(52.91)0.38 = 11.29 M (b) Using �he following equa

�ions and re

ferring Table 7, phase wise cos� and schedule es

�ima

�es can be calcula

�ed.

Ep = µ pE Dp = τ p DSof


� © New Ag

e In�erna


71

Sof�ware Projec

� Planning

Since size is only 12 KLOC, i� is an organic small model. Phase wise effor

� dis

�ribu

�ion is given below: Sys

�em Design De

�ailed Design Module Code & Tes

� In

�egr

a�ion & Tes

� = 0.16 x 52.91 = 8.465 PM = 0.26 x 52.91 = 13.756 PM = 0.42 x 52.91

= 22.222 PM = 0.16 x 52.91 = 8.465 Pm

Now Phase wise developmen� �ime dura

�ion is Sys

�em Design De

�ailed Design Module

Code & Tes� In

�egra

�ion & Tes

� = 0.19 x 11.29 = 2.145 M = 0.24 x 11.29 = 2.709

M = 0.39 x 11.29 = 4.403 M = 0.18 x 11.29 = 2.032 M72


� © New Ag

e In�erna


Sof�ware Projec

� Planning

COCOMO-IIThe following ca

�egories of applica

�ions / projec

�s are iden

�ified by COCOMO-II

and are shown in fig. 4 shown below:Applica

�ion genera

�ors & composi

�ion aids End user programming Applica

�ion compo

si�ion Sys

�em in

�egra

�ion Infras

�ruc

�ure

Fig. 4 : Ca�egories of applica

�ions / projec

�s


� © New Ag

e In�erna


73

Sof�ware Projec

� Planning

S�age No

S�age I

Model Name

Applica�ion for

�he

�ypes of projec

�s

Applica�ion composi

�ion

Applica�ions

Applica�ion composi

�ion es

�ima

�ion model

In addi�ion

�o applica

�ion composi

�ion

�ype of projec

�s,

�his model is also used

for pro�o�yping (if any) s

�age of applica

�ion genera

�ors, infras

�ruc

�ure & sys

�em in

�egra

�ion.

S�age II

Early design es�ima

�ion Applica

�ion genera

�ors, model infras

�ruc

�ure & sys

�em in�

egra�ion Applica

�ion genera

�ors, infras

�ruc

�ure & sys

�em in

�egra

�ion

Used in early design s�age of a projec

�, when less is known abou

� �he projec

�. U

sed af�er

�he comple

�ion of

�he de

�ailed archi

�ec�ure of

�he projec

�.

S�age III Pos

� archi

�ec�ure es

�ima

�ion model

Table 8: S�ages of COCOMO-II


� © New Ag

e In�erna


74

Sof�ware Projec

� Planning

Applica�ion Composi

�ion Es

�ima

�ion Model

Fig.5: S�eps for

�he es

�ima

�ion of effor

� in person mon

�hs


� © New Ag

e In�erna


75

Sof�ware Projec

� Planning

i. Assess objec� coun

�s: Es

�ima

�e �he number of screens, repor

�s and

3 GL componen�s �ha� will comprise

�his applica

�ion.

ii. Classifica�ion of complexi

�y levels: We have

�o classify each

objec� ins

�ance in

�o simple, medium and difficul

� complexi

�y levels depending on

values of i�s charac

�eris

�ics.

Table 9 (a): For screensSof


� © New Ag

e In�erna


76

Sof�ware Projec

� Planning

Table 9 (b): For repor�s


� © New Ag

e In�erna


77

Sof�ware Projec

� Planning

iii. Assign complexi�y weigh

� �o each objec

� : The weigh

�s are used

for �hree objec

� �ypes i.e., screen, repor

� and 3GL componen

�s using

�he Table 1

0.

Table 10: Complexi�y weigh

�s for each level


� © New Ag

e In�erna


78

Sof�ware Projec

� Planning

iv. De�ermine objec

� poin

�s: Add all

�he weigh

�ed objec

� ins

�ances

�o

ge� one number and

�his known as objec

�-poin

� coun

�.

v. Compu�e new objec

� poin

�s: We have

�o es

�ima

�e �he percen

�age

of reuse �o be achieved in a projec

�. Depending on

�he percen

�age reuse,

�he new

objec� poin

�s (NOP) are compu

�ed. (objec

� poin

�s) * (100-%reuse) NOP = --------

----------------------------------100 NOP are �he objec

� poin

�s �ha� will need

�o be developed and differ from

�he objec

� poin

� coun

� because

�here may be reuse

.


� © New Ag

e In�erna


79

Sof�ware Projec

� Planning

vi. Calcula�ion of produc

�ivi

�y ra

�e: The produc

�ivi

�y ra

�e can be

calcula�ed as: Produc

�ivi

�y ra

�e (PROD) = NOP/Person mon

�h

Table 11: Produc�ivi

�y values


� © New Ag

e In�erna


80

Sof�ware Projec

� Planning

vii. Compu�e �he effor

� in Persons-Mon

�hs: When PROD is known,

we may es�ima

�e effor

� in Person-Mon

�hs as: NOP Effor

� in PM = -----------PROD


� © New Ag

e In�erna


81

Sof�ware Projec

� Planning

Example: 4.9 Consider a da�abase applica

�ion projec

� wi

�h �he following charac

�e

ris�ics: I. The applica

�ion has 4 screens wi

�h 4 views each and 7 da

�a �ables fo

r 3 servers and 4 clien�s. II. The applica

�ion may genera

�e �wo repor

� of 6 sec

�ions each from 07 da

�a �ables for

�wo server and 3 clien

�s. There is 10% reuse o

f objec� poin

�s. The developer’s experience and capabili

�y in

�he similar environm

en� is low. The ma

�uri

�y of organiza

�ion in

�erms of capabili

�y is also low. Cal

cula�e �he objec

� poin

� coun

�, New objec

� poin

�s and effor

� �o develop such a pr

ojec�.


� © New Ag

e In�erna


82

Sof�ware Projec

� Planning

Solu�ion This projec

� comes under

�he ca

�egory of applica

�ion composi

�ion es

�ima�

ion model. Number of screens = 4 wi�h 4 views each Number of repor

�s = 2 wi

�h 6

sec�ions each From Table 9 we know

�ha� each screen will be of medium complexi

�y and each repor

� will be difficul

� complexi

�y. Using Table 10 of complexi

�y wei

gh�s, we may calcula

�e objec

� poin

� coun

�. = 4 x 2 + 2 x 8 = 24 24 * (100 -10) N

OP = -------------------- = 21.6 100Sof


� © New Ag

e In�erna


83

Sof�ware Projec

� Planning

Table 11 gives �he low value of produc

�ivi

�y (PROD) i.e. 7. NOP Effor

�s in PM =

----------PROD 21.6 Effor�s = ----------- = 3.086 PM 7


� © New Ag

e In�erna


84

Sof�ware Projec

� Planning

The Early Design ModelThe COCOMO-II models use

�he base equa

�ion of

�he form

PMnominal = A * (size)Bwhere PMnominal = Effor

� of

�he projec

� in person mon

�hs A = Cons

�an� represen

�i

ng �he nominal produc

�ivi

�y, provisionally se

� �o 2.5 B = Scale fac

�or Size = So

f�ware size


� © New Ag

e In�erna


85

Sof�ware Projec

� Planning

Scale fac�or

Preceden�ness

Explana�ion

Reflec�s �he previous experience on similar projec

�s. This is applicable

�o indi

viduals & organiza�ion bo

�h in

�erms of exper

�ise & experience Reflec

� �he degre

e of flexibili�y in

�he developmen

� process.

RemarksVery low means no previous experiences, Ex

�ra high means

�ha� organiza

�ion is co

mple�ely familiar wi

�h �his applica

�ion domain.

Developmen� flexibili

�y

Very low means a well defined process is used. Ex�ra high means

�ha� �he clien

�

gives only general goals. Very low means very li��

le analysis and Ex�ra high mea

ns comple�e and

�hrough risk analysis.

Archi�ec�ure/ resolu

�ion

Risk

Reflec� �he degree of risk analysis carried ou

�.

Con�… Table 12: Scaling fac

�ors required for

�he calcula

�ion of

�he value of B


� © New Ag

e In�erna


86

Sof�ware Projec

� Planning

Scale fac�or Explana

�ion

Reflec�s �he managemen

� skills.

�eam

RemarksVery low means no previous experiences, Ex

�ra high means

�ha� organiza

�ion is co

mple�ely familiar wi

�h �his applica

�ion domain. Very low means organiza

�ion has

no level a� all and ex

�ra high means organiza

�ion is rela

�ed as highes

� level of

SEI-CMM.

Team cohesion

Process ma�uri

�y

Reflec�s �he process ma

�uri

�y of

�he organiza

�ion. Thus i

� is dependen

� on SEI-C

MM level of �he organiza

�ion.

Table 12: Scaling fac�ors required for

�he calcula

�ion of

�he value of B


� © New Ag

e In�erna


87

Sof�ware Projec

� Planning

Scaling fac�ors Preceden

� ness Developmen

� flexibili

�y Archi

�ec�ure/ Risk resolu�

ion Team cohesion Process ma�uri

�y Very low 6.20 5.07 7.07 5.48 7.80 Low 4.96 4

.05 5.65 4.38 6.24 Nominal 3.72 3.04 4.24 3.29 4.68 High 2.48 2.03 2.83 2.19 3.12 Very high 1.24 1.01 1.41 1.10 1.56 Ex

�ra high 0.00 0.00 0.00 0.00 0.00

Table 13: Da�a for

�he Compu

�a�ion of B

The value of B can be calcula�ed as: B=0.91 + 0.01 * (Sum of ra

�ing on scaling f

ac�ors for

�he projec

�)


� © New Ag

e In�erna


88

Sof�ware Projec

� Planning

Early design cos� drivers

There are seven early design cos� drivers and are given below: i. Produc

� Reliab

ili�y and Complexi

�y (RCPX)

ii. Required Reuse (RUSE) iii. Pla�form Difficul

�y (PDIF) iv. Personnel Capabili�

y (PERS) v. Personnel Experience (PREX) vi. Facili�ies (FCIL) vii. Schedule (SC

ED)Sof


� © New Ag

e In�erna


89

Sof�ware Projec

� Planning

Pos� archi

�ec�ure cos

� drivers There are 17 cos

� drivers in

�he Pos

� Archi

�ec�ur

e model. These are ra�ed on a scale of 1

�o 6 as given below :

The lis� of seven

�een cos

� drivers is given below : i. Reliabili

�y Required (REL

Y)

ii. Da�abase Size (DATA) iii. Produc

� Complexi

�y (CPLX) iv. Required Reusabili

�y

(RUSE)Sof


� © New Ag

e In�erna


90

Sof�ware Projec

� Planning

v. Documen�a�ion (DOCU) vi. Execu

�ion Time Cons

�rain

� (TIME) vii. Main S

�orage C

ons�rain

� (STOR) viii.Pla

�form Vola

�ili

�y (PVOL) ix. Analys

� Capabili

�y (ACAP) x

. Programmers Capabili�y (PCAP) xi. Personnel Con

�inui

�y (PCON) xii. Analys

� Exp

erience (AEXP)Sof


� © New Ag

e In�erna


91

Sof�ware Projec

� Planning

xiii. Programmer Experience (PEXP) xiv. Language & Tool Experience (LTEX) xv. Use of Sof

�ware Tools (TOOL) xvi. Si

�e Loca

�ions & Communica

�ion Technology be

�wee

n Si�es (SITE) xvii. Schedule (SCED)


� © New Ag

e In�erna


92

Sof�ware Projec

� Planning

Mapping of early design cos� drivers and pos

� archi

�ec�ure cos

� drivers The 17 P

os� Archi

�ec�ure Cos

� Drivers are mapped

�o 7 Early Design Cos

� Drivers and are

given in Table 14Early Design Cos

� Drivers

RCPX RUSE PDIF PERS PREX FCIL SCED

Coun�er par

� Combined Pos

� Archi

�ec�ure Cos

� drivers

RELY, DATA, CPLX, DOCU RUSE TIME, STOR, PVOL ACAP, PCAP, PCON AEXP, PEXP, LTEX TOOL, SITE SCED


� © New Ag

e In�erna


Table 14: Mapping �able

93

Sof�ware Projec

� Planning

Produc� of cos

� drivers for early design model i. Produc

� Reliabili

�y and Comple

xi�y (RCPX): The cos

� driver combines four Pos

� Archi

�ec�ure cos

� drivers which

are RELY, DATA, CPLX and DOCU.


� © New Ag

e In�erna


94

Sof�ware Projec

� Planning

ii. Required Reuse (RUSE) : This early design model cos� driver is same as i

�s P

os� archi

�ec�ure Coun

�erpar

�. The RUSE ra

�ing levels are (as per Table 16):


� © New Ag

e In�erna


95

Sof�ware Projec

� Planning

iii. Pla�form Difficul

�y (PDIF) : This cos

� driver combines TIME, STOR and PVOL

of Pos� Archi

�ec�ure Cos

� Drivers.


� © New Ag

e In�erna


96

Sof�ware Projec

� Planning

iv. Personnel Capabili�y (PERS) : This cos

� driver combines

�hree Pos

� Archi

�ec�

ure Cos� Drivers. These drivers are ACAP, PCAP and PCON.


� © New Ag

e In�erna


97

Sof�ware Projec

� Planning

v. Personnel Experience (PREX) : This early design driver combines �hree Pos

� Ar

chi�ec�ure Cos

� Drivers, which are AEXP, PEXP and LTEX.


� © New Ag

e In�erna


98

Sof�ware Projec

� Planning

vi. Facili�ies (FCIL): This depends on

�wo Pos

� Archi

�ec�ure Cos

� Drivers, which

are TOOL and SITE.


� © New Ag

e In�erna


99

Sof�ware Projec

� Planning

vii.Schedule (SCED) : This early design cos� driver is

�he same as Pos

� Archi

�ec�

ure Coun�erpar

� and ra

�ing level are given below using

�able 16.


� © New Ag

e In�erna


100

Sof�ware Projec

� Planning

The seven early design cos� drivers have been conver

�ed in

�o numeric values wi

�h

a Nominal value 1.0. These values are used for �he calcula

�ion of a fac

�or call

ed “Effor� mul

�iplier” which is

�he produc

� of all seven early design cos

� drivers.

The numeric values are given in Table 15.

Table 15: Early design parame�ers


� © New Ag

e In�erna


101

Sof�ware Projec

� Planning

The early design model adjus�s �he nominal effor

� using 7 effor

� mul

�ipliers (EM

s). Each effor� mul

�iplier (also called drivers) has 7 possible weigh

�s as given

in Table 15. These fac�ors are used for

�he calcula

�ion of adjus

�ed effor

� as g

iven below:

PM adjus�ed

� 7 � = PM nominal × �∏ EM i � � i =7 �

PMadjus�ed effor

� may very even up

�o 400% from PMnominal Hence PMadjus

�ed is

�h

e fine �uned value of effor

� in

�he early design phase


� © New Ag

e In�erna


102

Sof�ware Projec

� Planning

Example: 4.10 A sof�ware projec

� of applica

�ion genera

�or ca

�egory wi

�h es

�ima

�e

d 50 KLOC has �o be developed. The scale fac

�or (B) has low preceden

�ness, high

developmen� flexibili

�y and low

�eam cohesion. O

�her fac

�ors are nominal. The ea

rly design cos� drivers like pla

�form difficul

� (PDIF) and Personnel Capabili

�y

(PERS) are high and o�hers are nominal. Calcula

�e �he effor

� in person mon

�hs fo

r �he developmen

� of

�he projec

�.


� © New Ag

e In�erna


103

Sof�ware Projec

� Planning

Solu�ion Here B = 0.91 + 0.01 * (Sum of ra

�ing on scaling fac

�ors for

�he projec�

) = 0.91 + 0.01 * (4.96 + 2.03 + 4.24 + 4.38 + 4.68) = 0.91 + 0.01(20.29)=1.1129 PMnominal = A*(size)B = 2.5 * (50)1.1129 = 194.41 Person mon

�hs The 7 cos

� dri

vers are PDIF = high (1.29) PERS = high (0.83) RCPX = nominal (1.0) RUSE = nominal (1.0) PREX = nominal (1.0) FCIL = nominal (1.0) SCEO = nominal (1.0)Sof


� © New Ag

e In�erna


104

Sof�ware Projec

� Planning

= 194.41 * [1.29 x 0.83) = 194.41 x 1.07 = 208.155 Person mon�hs


� © New Ag

e In�erna


105

Sof�ware Projec

� Planning

Pos� Archi

�ec�ure Model The pos

� archi

�ec�ure model is

�he mos

� de

�ailed es

�ima

�ion model and is in

�ended

�o be used when a sof

�ware life cycle archi

�ec�ure has

been comple�ed. This model is used in

�he developmen

� and main

�enance of sof

�wa

re produc�s in

�he applica

�ion genera

�ors, sys

�em in

�egra

�ion or infras

�ruc

�ure

sec�ors.

PM adjus�ed

� 17 � = PM nominal × �∏ EM i � � i =7 �

EM : Effor� mul

�iplier which is

�he produc

� of 17 cos

� drivers. The 17 cos

� driv

ers of �he Pos

� Archi

�ec�ure model are described in

�he

�able 16.


� © New Ag

e In�erna


106

Sof�ware Projec

� Planning

Table 16: Pos� Archi

�ec�ure Cos

� Driver ra

�ing level summary


� © New Ag

e In�erna


Con�…

107

Sof�ware Projec

� Planning


�ec�ure Cos

� Driver ra



� © New Ag

e In�erna


Con�…

108

Sof�ware Projec

� Planning


�ec�ure Cos

� Driver ra



� © New Ag

e In�erna


Con�…

109

Sof�ware Projec

� Planning


�ec�ure Cos

� Driver ra



� © New Ag

e In�erna


110

Sof�ware Projec

� Planning

Produc� complexi

�y is based on con

�rol opera

�ions, compu

�a�ional opera

�ions, dev

ice dependen� opera

�ions, da

�a managemen

� opera

�ions and user in

�erface manageme

n� opera

�ions. Module complexi

�y ra

�ing are given in

�able 17. The numeric value

s of �hese 17 cos

� drivers are given in

�able 18 for

�he calcula

�ion of

�he prod

uc� of effor

�s i.e., effor

� mul

�iplier (EM). Hence PM adjus

�ed is calcula

�ed whi

ch will be a be��

er and fine �uned value of effor

� in person mon

�hs.


� © New Ag

e In�erna


111

Sof�ware Projec

� Planning

Con�rol Opera

�ions Very Low S

�raigh

�-line code wi

�h a few nonnes

�ed s

�ruc

�ured p

rogramming opera�ors: Dos. Simple module composi

�ion via procedure calls or simp

le scrip�s. S

�raigh

� forward nes

�ing of s

�ruc

�ured programming opera

�ors. Mos

�ly

simple predica�es Compu

�a�ional Opera

�ions Evalua

�ion of simple expressions: e.

g., A=B+C*(D-E) Devicedependen� Opera

�ions Simple read, wri

�e s

�a�emen

�s wi

�h si

mple forma�s. Da

�a managemen

� Opera

�ions Simple arrays in main memory. Simple CO

TSDB queries, upda�es. User In

�erface Managemen

� Opera

�ions Simple inpu

� forms,

repor� genera

�ors.

Low

Evalua�ion of modera

�e-level expressions: e.g., D=SQRT(B**24*A*C)

No cognizance needed of par�icular processor or I/O device charac

�eris

�ics. I/O

done a� GET/PUT level.

Single file sub se��

ing wi�h no da

�a s

�ruc

�ure changes, no edi

�s, no in

�ermedia

�e files, Modera

�ely complex COTS-DB queries, upda

�es.

User of simple graphics user in�erface (GUI) builders.

Table 17: Module complexi�y ra

�ings


� © New Ag

e In�erna


Con�…

112

Sof�ware Projec

� Planning

Con�rol Opera

�ions Compu

�a�ional Opera

�ions Use of s

�andard ma

�hs and s

�a�is�ica

l rou�ines. Basic ma

�rix/ vec

�or opera

�ions. Devicedependen

� Opera

�ions I/O proc

essing includes device selec�ion, s

�a�us checking and error processing. Opera

�io

ns a� physical I/O level (physical s

�orage address

�ransla

�ions; seeks, read e

�c

.) Op�imized I/O overlap. Da

�a managemen

� Opera

�ions Mul

�i-file inpu

� and single

file ou�pu�. Simple s

�ruc

�ural changes, simple edi

�s. Complex COTS-DB queries,

upda�es. Simple

�riggers ac

�iva

�ed by da

�a s

�ream con

�en�s. Complex da

�a res

�ruc�

uring. User In�erface Managemen

� Opera

�ions Simple use of widge

� se

�.

Nominal

Mos�ly simple nes

�ing. Some in

�er module con

�rol Decision

�ables. Simple callbac

ks or message passing, including middleware suppor�ed dis

�ribu

�ed processing. Hi

ghly nes�ed s

�ruc

�ured programming opera

�ors wi

�h many compound predica

�es. Queu

e and s�ack con

�rol. Homogeneous, dis

�ribu

�ed processing. Single processor sof

�

real �ime con

�rol.

High

Basic numerical analysis: mul�ivaria

�e in

�erpola

�ion, ordinary differen

�ial equa�

ions. Basic �runca

�ion, round off concerns.

Widge� se

� developmen

� and ex

�ension. Simple voice I/O mul

�imedia.


�ings


� © New Ag

e In�erna


Con�…

113

Sof�ware Projec

� Planning

Con�rol Opera

�ions Compu

�a�ional Opera

�ions Device-dependen

� Opera

�ions Da

�a man

agemen� Opera

�ions Dis

�ribu

�ed da

�abase coordina

�ion. Complex

�riggers. Search o

p�imiza

�ion. User In

�erface Managemen

� Opera

�ions Modera

�ely complex 2D/3D, dyna

mic graphics, mul�imedia. Very High Reen

�ran

� and recursive coding. Fixed-priori�

y in�errup

� handling. Task synchroniza

�ion, complex callbacks, he

�erogeneous di

s�ribu

�ed processing. Single processor hard real

�ime con

�rol. Mul

�iple resource

scheduling wi�h dynamically changing priori

�ies. Microcode-level con

�rol. Dis

�r

ibu�ed hard real

�ime con

�rol. Difficul

� bu

� s�ruc

�ured numerical analysis: near

singular ma�rix equa

�ions, par

�ial differen

�ial equa

�ions. Simple paralleliza

�i

on. Rou�ines for in

�errup

� diagnosis, servicing, masking. Communica

�ion line han

dling. Performance in�ensive embedded sys

�ems. Device

�iming dependen

� coding, m

icro programmed opera�ions. Performance cri

�ical embedded sys

�ems.

Ex�ra High

Difficul� and uns

�ruc

�ured numerical analysis: highly accura

�e analysis of noisy

, s�ochas

�ic da

�a. Complex paralleliza

�ion.

Highly coupled, dynamic rela�ional and objec

� s�ruc

�ures. Na

�ural language da

�a

managemen�.

Complex mul�imedia, vir

�ual reali

�y.


�ings


� © New Ag

e In�erna


114

Sof�ware Projec

� Planning

Cos� Driver Very Low RELY DATA CPLX RUSE DOCU TIME STOR PVOL ACAP PCAP 1.50 1.37

0.87 1.22 1.16 0.89 0.75 0.75 Low 0.88 0.93 0.88 0.91 0.95 Ra�ing Nominal 1.00

1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 High 1.15 1.09 1.15 1.14 1.06 1.11 1.06 1.15 0.83 0.87 Very High 1.39 1.19 1.30 1.29 1.13 1.31 1.21 1.30 0.67 0.74 1.67 1.57 1.66 1.49 Ex

�ra High

Table 18: 17 Cos� Drivers


� © New Ag

e In�erna


Con�…

115

Sof�ware Projec

� Planning

Cos� Driver Very Low PCON AEXP PEXP LTEX TOOL SITE SCED 1.24 1.22 1.25 1.22 1.24

1.25 1.29 Low 1.10 1.10 1.12 1.10 1.12 1.10 1.10 Ra�ing Nominal 1.00 1.00 1.00

1.00 1.00 1.00 1.00 High 0.92 0.89 0.88 0.91 0.86 0.92 1.00 Very High 0.84 0.81 0.81 0.84 0.72 0.84 1.00 0.78 Ex

�ra High

Table 18: 17 Cos� Drivers


� © New Ag

e In�erna


116

Sof�ware Projec

� Planning

Schedule es�ima

�ion Developmen

� �ime can be calcula

�ed using PMadjus

�ed as a key

fac�or and

�he desired equa

�ion is:

TDEVnominal = [φ × ( PM adjusted )

( 0.28+ 0.2 ( B − 0.091))]

SCED % � 100

where Φ = constant, provisionally set to 3.67 TDEVnominal = calendar time in months with a scheduled constraint B = Scaling �actor PMadjusted = Estimated e��ort in Person months (a�ter adjustment)So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

117

So�tware Project PlanningSize measurement Size can be measured in any unit and the model can be calibrated accordingly. However, COCOMO II details are: i. Application composition model uses the size in object points. ii. The other two models use size in KLOC Early design model uses unadjusted �unction points. These �unction points are converted into KLOC using Table 19. Post architecture model may compute KLOC a�ter de�ining LOC counting rules. I� �unction points are used, then use unadjusted �unction points and convert it into KLOC using Table 19.118

So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

So�tware Project PlanningLanguage Ada AI Shell APL Assembly Assembly (Macro) ANSI/Quick/Turbo Basic Basic�Compiled Basic�Interpreted C C++ SLOC/U�P 71 49 32 320 213 64 91 128 128 29Table 19: Converting �unction points to lines o� codeSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

Cont…119

So�tware Project PlanningLanguage ANSI Cobol 85

�ortan 77

�orth Jovial Lisp Modula 2 Pascal Prolog Report

Generator Spreadsheet SLOC/U�P 91 105 64 105 64 80 91 64 80 6

Table 19: Converting �unction points to lines o� codeSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

120

So�tware Project PlanningExample: 4.11 Consider the so�tware project given in example 4.10. Size and scale �actor (B) are the same. The identi�ied 17 Cost drivers are high reliability (RELY), very high database size (DATA), high execution time constraint (TIME), very high analyst capability (ACAP), high programmers capability (PCAP). The other cost drivers are nominal. Calculate the e��ort in Person�Months �or the development o� the project.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

121

So�tware Project PlanningSolution

Here PMnominal

B = 1.1129 = 194.41 Person�monthsPM adjusted

� 17 � = PM nominal × �∏ EM i � � i =7 �= 194.41 x (1.15 x 1.19 x 1.11 x 0.67 x 0.87) = 194.41 x 0.885 = 172.05 Person�months


122

So�tware Project PlanningPutnam Resource Allocation ModelNorden o� IBM Rayleigh curve Model �or a range o� hardware development projects.Overall Curve Design and Coding

Persons

Time�ig.6: The Rayleigh manpower loading curveSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

123

So�tware Project PlanningPutnam observed that this curve was a close approximation at project level and so�tware subsystem level.No. o� projects = 150So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

124

So�tware Project PlanningThe Norden / Rayleigh Curve The curve is modeled by di��erential equationdy − at 2 m(t ) = = 2kate dtdy dt�� (1)= manpower utilization rate per unit time = parameter that a��ects the shape o� the curve = area under curve in the interval [0, ∞ ] = elapsed timeSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

a K t

125

So�tware Project PlanningOn Integration on interval [o, t] y(t) = K [1�e�at2] ��(2) Where y(t): cumulative manpower used upto time t. y(0) = 0 y(∞) = k The cumulative manpower is null at the start o� the project, and grows monotonically towards the total e��ort K (area under the curve).So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

126

So�tware Project Planningd2y − at 2 = 2kae [1 − 2at 2 ] = 0 dt 2 1 2 td = 2a“td”: time where maximum e��ort rate occurs Replace “td” �or t in equation (2)� � 1 − e 2 t d2 E = y (t ) = k � � E = y ( t ) = 0 . 3935 k2 td

� � = K (1 − e − 0 .5 ) � �

a=

1 2 2t dSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

127

So�tware Project Planning1 Replace “a” with 2 in the Norden/Rayleigh model. By 2t d making this substitution in equation we have2K2 2t d − t22 2t d

m(t ) =

te

K − 2td2 = 2 te tdSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

t2

128

So�tware Project Planninga=2

a=0.5 m (t) Persona=0.125

a=0.222

Time (years) �ig.7: In�luence o� parameter ‘a’ on the manpower distribution


129

So�tware Project PlanningAt time t=td, peak manning m (td) is obtained and denoted by mo.

mo =k td m0 e

k td e

= Total project cost/e��ort in person�years. = Delivery time in years = No. o� persons employed at the peak = 2.71828


130

So�tware Project PlanningExample: 4.12A so�tware development project is planned to cost 95 MY in a period o� 1 year and 9 months. Calculate the peak manning and average rate o� so�tware team build up.


131

So�tware Project PlanningSolutionSo�tware development cost Peak development time Peak manning k=95 MY td = 1.75 years mo=k td e

95 = 32.94 = 33 persons 1.75 × 1.648Average rate o� so�tware team build up=

m0 td

=

33 = 18.8 persons / year or 1.56 person / month 1.75So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

132

So�tware Project PlanningExample: 4.13Consider a large�scale project �or which the manpower requirement is K=600 PY and the development time is 3 years 6 months. (a)Calculate the peak manning and peak time. (b)What is the manpower cost a�ter 1 year and 2 months?So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

133

So�tware Project PlanningSolution(a) We know td=3 years and 6 months = 3.5 years NOWm0 = K td e

∴ m0 =

600/(3.5x1.648) ≅ 104 persons


134

So�tware Project Planning(b) We know

y (t ) = K 1 − e

[

− at 2

]

t = 1 year and 2 months = 1.17 yearsa= 1 1 = = 0.041 2 2 2t d 2 × (3.5)

y (1 .17 ) = 600 1 − e= 32.6 PY

[

− 0 . 041 (1 . 17 ) 2

]135


So�tware Project PlanningDi��iculty MetricSlope o� manpower distribution curve at start time t=0 has some use�ul properties.

d2y − at 2 m� (t ) = 2 = 2kae (1 − 2at 2 ) dt

Then, �or t=02K K m

� (0) = 2 Ka = 2 = 2 2t d t d


136

So�tware Project PlanningK The ratio t 2 is called di��iculty and denoted by D, d which is measured in person/year :

k D= 2 persons/year td


137

So�tware Project PlanningProject is di��icult to develop i�Manpower demand is high

When time schedule is short


138

So�tware Project PlanningPeak manning is de�ined as:m0 =

k td e

k m0 e D= 2 = td td

Thus di��icult projects tend to have a higher peak manning �or a given development time, which is in line with Norden’s observations relative to the parameter “a”.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

139

So�tware Project PlanningManpower buildup

D is dependent upon “K”. The derivative o� D relative to “K” and “td” areD� (t d ) =

−2k3 td

persons / year 2

1 D � (k ) = 2 year − 2 td


140

So�tware Project PlanningD1(K) will always be very much smaller than the absolute value o� D1(td). This di��erence in sensitivity is shown by considering two projects Project A Project B : Cost = 20 PY & td = 1 year : Cost = 120 PY & td = 2.5 years

The derivative values are Project A Project B : D� (td) = �40 & D�(K) = 1 : D� (td) = �15.36 & D�(K) = 0.16This shows that a given so�tware development is time sensitive.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

141

So�tware Project PlanningPutnam observed that Di��iculty derivative relative to time Behavior o� s/w development I� project scale is increased, the development time also increase to such an extent that k remains constant 3 td around a value which could be 8,15,27.


142

So�tware Project PlanningIt is represented by D0 and can be expressed as:k D0 = 3 person / year 2 td

D0 =8, new s/w with many inter�aces & interactions with other systems. D0 =15, New standalone system. D0 =27, The so�tware is rebuild �orm existing so�tware.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

143

So�tware Project PlanningExample: 4.14Consider the example 4.13 and calculate the di��iculty and manpower build up.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

144

So�tware Project PlanningSolutionWe know

K Di��iculty D = 2 td600 = = 49 person / year 2 (3.5)

Manpower build up can be calculated by �ollowing equationK D0 = 3 td= 600 = 14 person / year 2 (3.5)3145


So�tware Project PlanningProductivity Versus Di��icultyProductivity = No. o� LOC developed per person�month P ∞ Dβ Avg. productivity P=LOC produced cumulative manpower used to produce code146

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

Software Project PlanningP = S/EP = φD −2 / 3 S = φD − 2 / 3 E = φD − 2 / 3 (0.3935 K )2 3

�k � S = φ � 2 � k (0.3935) � td �

−

S = 0.3935 φ K

1/ 3

td

4/3


147

So�tware Project Planning0.39 φ

c Technology �actor

Hardware constraints

Experience Complexity

Programming environment


148

So�tware Project PlanningC 610 – 57314 K : P�Y T : YearsS = CK

1/ 3 4 / 3td

C = S .K The trade o�� o� time versus cost−1 / 3 −4 / 3td

K tK

1/ 3 4 / 3 d

= S /C3

1 � S � = � 4 � td � C �


149

So�tware Project PlanningC = 5000 S = 5,00,000 LOC

1 3 K = 4 (100 ) tdK (P�Y) 1600 3906 6664 12346150

td (years) 5.0 4.0 3.5 3.0

Table 20: (Manpower versus development time)So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

So�tware Project PlanningDevelopment SubcycleAll that has been discussed so �ar is related to project li�e cycle as represented by project curve Manpower distribution Project

Requirements & Speci�icationDesign code development

Test & Validation

Ma

inte nanTime

ce151�ig.8: Project li�e cycleSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

So�tware Project PlanningProject li�e cycleProject curve is the addition o� two curvesDevelopment Curve

Test & Validation Curve152


So�tware Project Planningmd (t) = 2kdbt e�bt2 ∴ yd (t) = Kd [1�e�bt2]An examination o� md(t) �unction shows a non�zero value o� md at time td. This is because the manpower involved in design & coding is still completing this activity a�ter td in �orm o� rework due to the validation o� the product. Nevertheless, �or the model, a level o� completion has to be assumed �or development. It is assumed that 95% o� the development will be completed by the time td.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

153

So�tware Project Planning−bt 2 yd (t ) = 1 − e = 0.95 Kd

∴ We may say that

1 b= 2 2tod

Tod: time at which development curve exhibits a peak manning.

t od

td = 6So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

154

So�tware Project PlanningRelationship between Kd & K must be established. At the time o� origin, both cycles have the same slope.

K K d � dmd � � dm � � � = 2 = 2 =� � � dt � o t d tod � dt � oKd=K/6

Kd K D = 2 = 2 td t odSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

155

So�tware Project PlanningThis does not apply to the manpower build up D0.

Kd K Do = 3 = 3 td 6todConte investigated that Larger projects Medium & small projects reasonable overestimate


156

So�tware Project PlanningExample: 4.15A so�tware development requires 90 PY during the total development sub�cycle. The development time is planned �or a duration o� 3 years and 5 months (a)Calculate the manpower cost expended until development time (b) Determine the development peak time (c) Calculate the di��iculty and manpower build up.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

157

So�tware Project PlanningSolution(a) Duration td = 3.41 years We know �rom equation−btd yd (t ) = 1 − e = 0.95 Kd

yd (t d ) = 0.95 Kd

Yd (t d ) = 0.95 × 90= 85.5 PY


158

So�tware Project Planning(b) We know �rom equationt od

td = 6

t od

td = = 3 . 41 / 2 . 449 = 1 . 39 years 6

≅ 17 months


159

So�tware Project Planning(c) Total Manpower development

K d = yd (t d ) / 0.95= 85.5 / 0.95 = 90

K = 6 K d = 90 × 6 = 540 PY2 D = K / t d = 540 /(3.41) 2 = 46

persons/years persons/years2

K Do = 3 = 540 /(3.41) 3 = 13.6 td


160

So�tware Project PlanningExample:4.16

A so�tware development �or avionics has consumed 32 PY up to development cycle and produced a size o� 48000 LOC. The development o� project was completed in 25 months. Calculate the development time, total manpower requirement, development peak time, di��iculty, manpower build up and technology �actor.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

161

So�tware Project PlanningSolution:

Development time td = 25 months = 2.08 yearsYd (t d ) 32 = = 33.7 PY Total manpower development k d = 0.95 0.95

Development peak time

t od =

(t d ) 6

= 0.85 years = 10 months

K = 6Kd = 6 x 33.7 = 202 PYk 202 D= 2 = = 46.7 pesons / years 2 t d (2.08)So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

162

So�tware Project PlanningD0 = k3 td

=

202 ( 2.08)3

= 22.5 Persons / year 2

Technology �actorC = SK

−1 / 3

td

−4 / 3

= 3077


163

So�tware Project PlanningExample 4.17

What amount o� so�tware can be delivered in 1 year 10 months in an organization whose technology �actor is 2400 i� a total o� 25 PY is permitted �or development e��ort.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

164

So�tware Project PlanningSolution:

td = 1.8 years Kd = 25 PY K = 25 x 6 = 150 PY C = 2400

We know

S = CK

1/3

td

4/3

= 2400 x 5.313 x 2.18 = 27920 LOC


165

So�tware Project PlanningExample 4.18

The so�tware development organization developing real time so�tware has been assessed at technology �actor o� 2200. The maximum value o� manpower build up �or this type o� so�tware is Do=7.5. The estimated size to be developed is S=55000 LOC. (a) Determine the total development time, the total development manpower cost, the di��iculty and the development peak manning. (b) The development time determined in (a) is considered too long. It is recommended that it be reduced by two months. What would happen?So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

166

So�tware Project PlanningSolutionWe have

S = CK t d�s� 4 � � = ktd �c�3

1/ 3

4/3

S 7 which is also equivalent to � � = Do t d � � �C �� 1 �S� td = � � � � D0 � C � �3 1/ 7

3

then

� � � �


167

So�tware Project PlanningSince S = 25 C

td = 3 years3 K = D0t d = 7.5 × 27 = 202 PY

202 Total development manpower cost Kd = = 33.75PY 06

D = D0td = 22.5 persons / year td 3 tod = = = 1.2 years 6 6So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

168

So�tware Project PlanningMd(t) = 2kd Yd(t) = kd Here Peak manning�bt2 bte�bt2 (1�e)

t = tod= mod = Dtod e−1 / 2

= 22.5 x 1.2 x .606 = 16 persons


169

So�tware Project PlanningIII. I� development time is reduced by 2 monthsDeveloping s/w at higher manpower build�upProducing less so�twareSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

170

So�tware Project Planning(i) Increase Manpower Build�up1�S� Do = 7 � � td � C �

3

Now td = 3 years – 2 months = 2.8 yearsDo = ( 25)3 /( 2.8) 7 = 11.6 persons / years3 k = D0t d = 254 PY

254 Kd = = 42.4 PY 6So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

171

So�tware Project PlanningD = D0td = 32.5 persons / year The peak time is tod = 1.14 years Peak manning mod = Dtod e�0.5 = 32.5 x 1.14 x 0.6 = 22 persons Note the huge increase in peak manning & manpower cost.


172

So�tware Project Planning(ii) Produce Less So�tware�S� 7 = D0t d = 7.5 × (2.8) 7 = 10119.696 � � �C ��S� � � = 21.62989 �C �3

3

Then �orC=2200 S=47586 LOC


173

Productivity versus di��icultExample 4.19

A stand alone project �or which the size is estimated at 12500 LOC is to be developed in an environment such that the technology �actor is 1200. Choosing a manpower build up Do=15, Calculate the minimum development time, total development man power cost, the di��iculty, the peak manning, the development peak time, and the development productivity.


174

So�tware Project PlanningSolutionSize (S) Technology �actor (C) Manpower buildup (Do) Now = 12500 LOC = 1200 = 154 S = CK 1/ 3t d / 3

S 4 = K 1 / 3t d / 3 C

�S� 4 � � = Kt d �C �So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

3

175

So�tware Project PlanningK Also we know Do = 3 td3 3 K = Dot d = Dot d

Hence

�S� 7 � � = Dotd �C�3

3

� 12500 � 7 � = 15t d Substituting the values, we get � � 1200 �� (10.416) � td = � � 15 � �3 1/ 7

t d = 1.85 yearsSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

176

So�tware Project Planning(i) Hence Minimum development time (td)=1.85 yearsK (ii) Total development manpower cost K d = 6

Hence

3 K =15td

=15(1.85)3=94.97 PYK 94.97 Kd = = = 15.83 PY 6 6

(iii) Di��icultyD=

K2 td

=

94.97 (1.85)2

= 27.75 Persons / year


177

So�tware Project Planning(iv) Peak Manning

m0 =

K td e

94.97 = = 31.15Persons 1.85×1.648

(v) Development Peak time

tod

td = 6

1.85 = = 0.755 years 2.449So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

178

So�tware Project Planning(vi) Development ProductivityNo .o� lines o� code ( S ) = e��ort ( K d )12500 = = 789.6 LOC / PY 15.83


179

So�tware Project PlanningSo�tware Risk ManagementWe So�tware developers are extremely optimists. We assume, everything will go exactly as planned. Other view not possible to predict what is going to happen ? So�tware surprises Never good newsSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

180

So�tware Project PlanningRisk management is required to reduce this surprise �actor Dealing with concern be�ore it becomes a crisis. Quanti�y probability o� �ailure & consequences o� �ailure.


181

So�tware Project PlanningWhat is risk ?Tomorrow’s problems are today’s risks.

“Risk is a problem that may cause some loss or threaten the success o� the project, but which has not happened yet”.


182

So�tware Project PlanningRisk management is the process o� identi�ying addressing and eliminating these problems be�ore they can damage the project. Current problems &Potential Problems


183

So�tware Project PlanningTypical So�tware RiskCapers Jones has identi�ied the top �ive risk �actors that threaten projects in di��erent applications. 1. Dependencies on outside agencies or �actors. • • • • Availability o� trained, experienced persons Inter group dependencies Customer��urnished items or in�ormation Internal & external subcontractor relationshipsSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

184

So�tware Project Planning2. Requirement issues Uncertain requirements

Wrong product or Right product badly Either situation results in unpleasant surprises and unhappy customers.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

185

So�tware Project Planning• Lack o� clear product vision • Lack o� agreement on product requirements • Unprioritized requirements • New market with uncertain needs • Rapidly changing requirements • Inadequate Impact analysis o� requirements changesSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

186

So�tware Project Planning3. Management Issues Project managers usually write the risk management plans, and most people do not wish to air their weaknesses in public. • • • • • • Inadequate planning Inadequate visibility into actual project status Unclear project ownership and decision making Sta�� personality con�licts Unrealistic expectation Poor communicationSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

187

So�tware Project Planning4. • • • • • Lack o� knowledge Inadequate training Poor understanding o� methods, tools, and techniques Inadequate application domain experience New Technologies Ine��ective, poorly documented or neglected processesSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

188

So�tware Project Planning5. • • • • Other risk categories Unavailability o� adequate testing �acilities Turnover o� essential personnel Unachievable per�ormance requirements Technical approaches that may not work


189

So�tware Project PlanningRisk Management Activities

Risk Identi�ication Risk Assessment Risk Management Risk Control�ig. 9: Risk Management Activities

Risk Analysis Risk Prioritization Risk Management Planning Risk Monitoring Risk Resolution190


So�tware Project PlanningRisk AssessmentIdenti�ication o� risks Risk analysis involves examining how project outcomes might change with modi�ication o� risk input variables. Risk prioritization �ocus �or severe risks. Risk exposure: It is the product o� the probability o� incurring a loss due to the risk and the potential magnitude o� that loss.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

191

So�tware Project PlanningAnother way o� handling risk is the risk avoidance. Do not do the risky things! We may avoid risks by not undertaking certain projects, or by relying on proven rather than cutting edge technologies.


192

So�tware Project PlanningRisk ControlRisk Management Planning produces a plan �or dealing with each signi�icant risks. Record decision in the plan. Risk resolution is the execution o� the plans o� dealing with each risk.


193

Multiple Choice QuestionsNote: Choose most appropriate answer o� the �ollowing questions:4.1 A�ter the �inalization o� SRS, we may like to estimate (a) Size (b) Cost (c) Development time (d) All o� the above. 4.2 Which one is not a size measure �or so�tware (a) LOC (b) �unction Count (c) Cyclomatic Complexity (d) Halstead’s program length 4.3

�unction count method was developed by (a) B.Beizer (b) B.Boehm (c

) M.halstead (d) Alan Albrecht 4.4 �unction point analysis (

�PA) method decompos

es the system into �unctional units. The total number o� �unctional units are (a) 2 (b) 5 (c) 4 (d) 1


194

Multiple Choice Questions4.5 I

�PUG stand �or (a) Initial �unction point uni�orm group (b) International �

unction point uni�orm group (c) International �unction point user group (d) Initial �unction point user group 4.6 �unction point can be calculated by (a) U�P * CA� (b) U

�P *

�AC (c) U

�P * Cost (d) U

�P * Productivity 4.7 Putnam resource allo

cation model is based on (a) �unction points (b) Norden/ Rayleigh curve (c) Putn

am theory o� so�tware management (d) Boehm’s observation on manpower utilisation rate 4.8 Manpower buildup �or Putnam resource allocation model is2 ( a ) K / t d persons / year 2 2 (c ) K / t d persons / year 3 (b) K / t d persons / year 2 3 ( d ) K / t d persons / year


195

Multiple Choice Questions4.9 COCOMO was developed initially by (a) B.W.Bohem (c) B.Beizer (b) Gregg Rothermal (d) Rajiv Gupta

4.10 A COCOMO model is (a) Common Cost estimation model (b) Constructive cost Estimation model (c) Complete cost estimation model (d) Comprehensive Cost estimation model 4.11 Estimation o� so�tware development e��ort �or organic so�tware is COCOMO is (a) E=2.4(KLOC)1.05PM (b) E=3.4(KLOC)1.06PM (c) E=2.0(KLOC)1.05PM (d) E�2.4(KLOC)1.07PM 4.12 Estimation o� size �or a project is dependent on (a) Cost (b) Schedule (c) Time (d) None o� the above 4.13 In �unction point analysis, number o� Complexity adjustment �actor are (a) 10 (b) 20 (c) 14 (d) 12So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

196

Multiple Choice Questions4.14 COCOMO�II estimation model is based on (a) Complex approach (b) Algorithm approach (c) Bottom up approach (d) Top down approach 4.15 Cost estimation �or a project may include (a) So�tware Cost (b) Hardware Cost (c) Personnel Costs (d) All o� the above 4.16 In COCOMO model, i� project size is typically 2�50 KLOC, then which mode is to be selected? (a) Organic (b) Semidetached (c) Embedded (d) None o� the above 4.17 COCOMO�II was developed at (a) University o� Maryland (c) IBM (b) University o� Southern Cali�ornia (d) AT & T Bell labs4.18 Which one is not a Category o� COCOMO�II (a) End User Programming (b) In�rastructure Sector (c) Requirement Sector (d) System IntegrationSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

197

Multiple Choice Questions4.19 Which one is not an in�rastructure so�tware? (a) Operating system (b) Database management system (c) Compilers (d) Result management system 4.20 How many stages are in COCOMO�II? (a) 2 (b) 3 (c) 4 (d) 5 4.21 Which one is not a stage o� COCOMO�II? (a) Application Composition estimation model (b) Early design estimation model (c) Post architecture estimation model (d) Comprehensive cost estimation model 4.22 In Putnam resource allocation model, Rayleigh curve is modeled by the equation

(a ) m(t ) = 2at e − at − at 2 (c) m(t ) = 2 Kat e

2

(b) m(t ) = 2 Kt e − at − at 2 ( d ) m(t ) = 2 Kbt e198

2


Multiple Choice Questions4.23 In Putnam resource allocation model, technology �actor ‘C’ is de�ined as− (a) C = SK −1/ 3t d 4 / 3 − (c) C = SK 1/ 3t d 4 / 3 4 (b) C = SK 1/ 3t d / 3 4 (d ) C = SK −1/ 3t d / 3

4.24 Risk management activities are divided in (a) 3 Categories (b) 2 Categories (c) 5 Categories (d) 10 Categories 4.25 Which one is not a risk management activity? (a) Risk assessment (b) Risk control (c) Risk generation (d) None o� the above


199

Exercises4.1 What are various activities during so�tware project planning? 4.2 Describe any two so�tware size estimation techniques. 4.3 A proposal is made to count the size o� ‘C’ programs by number o� semicolons, except those occurring with literal strings. Discuss the strengths and weaknesses to this size measure when compared with the lines o� code count. 4.4 Design a LOC counter �or counting LOC automatically. Is it language dependent? What are the limitations o� such a counter? 4.5 Compute the �unction point value �or a project with the �ollowing in�ormation domain characteristics. Number o� user inputs = 30 Number o� user outputs = 42 Number o� user enquiries = 08 Number o� �iles = 07 Number o� external inter�aces = 6 Assume that all complexity adjustment values are moderate.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

200

Exercises4.6 Explain the concept o� �unction points. Why �Ps are becoming acceptable in industry? 4.7 What are the size metrics? How is �unction point metric advantageous over LOC metric? Explain. 4.8 Is it possible to estimate so�tware size be�ore coding? Justi�y your answer with suitable example. 4.9 Describe the Albrecht’s �unction count method with a suitable example. 4.10 Compute the �unction point �P �or a payroll program that reads a �ile o� employee and a �ile o� in�ormation �or the current month and prints cheque �or all the employees. The program is capable o� handling an interactive command to print an individually requested cheque immediately.


201

Exercises4.11 Assume that the previous payroll program is expected to read a �ile containing in�ormation about all the cheques that have been printed. The �ile is supposed to be printed and also used by the program next time it is run, to produce a report that compares payroll expenses o� the current month with those o� the previous month. Compute �unctions points �or this program. Justi�y the di��erence between the �unction points o� this program and previous one by considering how the complexity o� the program is a��ected by adding the requirement o� inter�acing with another application (in this case, itsel�). 4.12 Explain the Walson & �elix model and compare with the SEL model. 4.13 The size o� a so�tware product to be developed has been estimated to be 22000 LOC. Predict the manpower cost (e��ort) by Walston��elix Model and SEL model. 4.14 A database system is to be developed. The e��ort has been estimated to be 100 Persons�Months. Calculate the number o� lines o� code and productivity in LOC/Person�Month.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

202

Exercises4.15 Discuss various types o� COCOMO mode. Explain the phase wise distribution o� e��ort. 4.16 Explain all the levels o� COCOMO model. Assume that the size o� an organic so�tware product has been estimated to be 32,000 lines o� code. Determine the e��ort required to developed the so�tware product and the nominal development time. 4.17 Using the basic COCOMO model, under all three operating modes, determine the per�ormance relation �or the ratio o� delivered source code lines per person�month o� e��ort. Determine the reasonableness o� this relation �or several types o� so�tware projects. 4.18 The e��ort distribution �or a 240 KLOC organic mode so�tware development project is: product design 12%, detailed design 24%, code and unit test 36%, integrate and test 28%. How would the �ollowing changes, �rom low to high, a��ect the phase distribution o� e��ort and the total e��ort: analyst capability, use o� modern programming languages, required reliability, requirements volatility?So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

203

Exercises4.19 Speci�y, design, and develop a program that implements COCOMO. Using re�erence as a guide, extend the program so that it can be used as a planning tool. 4.20 Suppose a system �or o��ice automation is to be designed. It is clear �rom requirements that there will be �ive modules o� size 0.5 KLOC, 1.5 KLOC, 2.0 KLOC, 1.0 KLOC and 2.0 KLOC respectively. Complexity, and reliability requirements are high. Programmer’s capability and experience is low. All other �actors are o� nominal rating. Use COCOMO model to determine overall cost and schedule estimates. Also calculate the cost and schedule estimates �or di��erent phases. 4.21 Suppose that a project was estimated to be 600 KLOC. Calculate the e��ort and development time �or each o� the three modes i.e., organic, semidetached and embedded. 4.22 Explain the COCOMO�II in detail. What types o� categories o� projects are identi�ied?So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

204

Exercises4.23 Discuss the In�rastructure Sector o� COCOMO�II. 4.24 Describe various stages o� COCOMO�II. Which stage is more popular and why? 4.25 A so�tware project o� application generator category with estimated size o� 100 KLOC has to be developed. The scale �actor (B) has high percedentness, high development �lexibility. Other �actors are nominal. The cost drivers are high reliability, medium database size, high Personnel capability, high analyst capability. The other cost drivers are nominal. Calculate the e��ort in Person�Months �or the development o� the project. 4.26 Explain the Putnam resource allocation model. What are the limitations o� this model? 4.27 Describe the trade�o�� between time versus cost in Putnam resource allocation model. 4.28 Discuss the Putnam resources allocation model. Derive the time and e��ort equations.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

205

Exercises4.29 Assuming the Putnam model, with S=100,000 , C=5000, Do=15, Compute development time td and manpower development Kd. 4.30 Obtain so�tware productivity data �or two or three so�tware development programs. Use several cost estimating models discussed in this chapter. How to the results compare with actual project results? 4.31 It seems odd that cost and size estimates are developed during so�tware project planning�be�ore detailed so�tware requirements analysis or design has been conducted. Why do we think this is done? Are there circumstances when it should not be done? 4.32 Discuss typical so�tware risks. How sta�� turnover problem a��ects so�tware projects? 4.33 What are risk management activities? Is it possible to prioritize the risk?


206

Exercises4.34 What is risk exposure? What techniques can be used to control each risk? 4.35 What is risk? Is it economical to do risk management? What is the e��ect o� this activity on the overall cost o� the project? 4.36 There are signi�icant risks even in student projects. Analyze a student project and list all the risk.


207


1

So�tware DesignMore creative than analysis Problem solving activityWHAT IS DESIGN

‘HOW’So�tware design document (SDD)So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

2

So�tware DesignInitial requirements Gather data on user requirements Analyze requirements data Validate the design against the requirements Conceive o� a high level design Re�ine & document the design Completed design Obtain answers to requirement questions�ig. 1 : Design �rameworkSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

3

So�tware Designdesign

Satis�yCustomer

Developers (Implementers)


4

So�tware DesignConceptual Design and Technical DesignD e s i g n e r s

What Conceptual design

How Technical design

Customer

A two part design process �ig. 2 : A two part design process


System Builders5

So�tware DesignConceptual design answers : Where will the data come �rom ? What will happen to data in the system? How will the system look to users? What choices will be o��ered to users? What is the timings o� events? How will the reports & screens look like?


6

So�tware DesignTechnical design describes :Hardware con�iguration So�tware needs Communication inter�aces I/O o� the system So�tware architecture Network architecture Any other thing that translates the requirements in to a solution to the customer’s problem.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

7

So�tware DesignThe design needs to be Correct & complete Understandable At the right level Maintainable


8

So�tware DesignIn�ormal design outlineIn�ormal designMore �ormal design�inished design�ig. 3 : The trans�ormation o� an in�ormal design to a detailed design.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

9

So�tware DesignMODULARITY There are many de�initions o� the term module. Range is �rom : i. �ortran subroutine

ii. Ada package iii. Procedures & �unctions o� PASCAL & C iv. C++ / Java classes v. Java packages vi. Work assignment �or an individual programmerSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

10

So�tware DesignAll these de�initions are correct. A modular system consist o� well de�ined manageable units with well de�ined inter�aces among the units.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

11

So�tware DesignProperties : i. Well de�ined subsystem ii. Well de�ined purpose iii. Can be separately compiled and stored in a library. iv. Module can use other modules v. Module should be easier to use than to build vi. Simpler �rom outside than �rom the inside.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

12

So�tware DesignModularity is the single attribute o� so�tware that allows a program to be intellectually manageable. It enhances design clarity, which in turn eases implementation, debugging, testing, documenting, and maintenance o� so�tware product.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

13

So�tware Design�ig. 4 : Modularity and so�tware costSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

14

So�tware DesignModule Coupling Coupling is the measure o� the degree o� interdependence between modules.

(Uncoupled : no dependencies) (a)So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

15

So�tware DesignLoosely coupled: some dependencies (B)

Highly coupled: many dependencies (C)�ig. 5 : Module coupling


16

So�tware DesignThis can be achieved as: Controlling the number o� parameters passed amongst modules. Avoid passing undesired data to calling module. Maintain parent / child relationship between calling & called modules. Pass data, not the control in�ormation.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

17

So�tware DesignConsider the example o� editing a student record in a ‘student in�ormation system’.Edit student record Student name, student ID, address, course Student record EO

� Edit student record Student ID Student record EO

�Retrieve student record Poor design: Tight Coupling

Retrieve student record Good design: Loose Coupling�ig. 6 : Example o� couplingSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

18

So�tware DesignData coupling Stamp coupling Control coupling External coupling Common coupling Content coupling Worst Best�ig. 7 : The types o� module couplingGiven two procedures A & B, we can identi�y number o� ways in which they can be coupled.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

19

So�tware DesignData couplingThe dependency between module A and B is said to be coupled i� their dependency is based on the �act communicate by only passing o� data. Other communicating through data, the two modules independent. data they than are

Stamp couplingStamp coupling occurs between module A and B when complete data structure is passed �rom one module to another.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

20

So�tware DesignControl couplingModule A and B are said to be control coupled i� they communicate by passing o� control in�ormation. This is usually accomplished by means o� �lags that are set by one module and reacted upon by the dependent module.

Common couplingWith common coupling, module A and module B have shared data. Global data areas are commonly �ound in programming languages. Making a change to the common data means tracing back to all the modules which access that data to evaluate the e��ect o� changes.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

21

So�tware Design�ig. 8 : Example o� common couplingSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

22

So�tware DesignContent couplingContent coupling occurs when module A changes data o� module B or when control is passed �rom one module to the middle o� another. In �ig. 9, module B branches into D, even though D is supposed to be under the control o� C.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

23

So�tware Design�ig. 9 : Example o� content couplingSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

24

So�tware DesignModule CohesionCohesion is a measure o� the degree to which the elements o� a module are �unctionally related.

Module strength�ig. 10 : Cohesion=Strength o� relations within modulesSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

25

So�tware DesignTypes o� cohesion�unctional cohesion Sequential cohesion Procedural cohesion Temporal cohesion Logical cohesion Coincident cohesion


26

So�tware Design�unctional Cohesion Sequential Cohesion Communicational Cohesion Procedural Cohesion Temporal Cohesion Logical Cohesion Coincidental Cohesion Worst (low) Best (high)�ig. 11 : Types o� module cohesionSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

27

So�tware Design�unctional CohesionA and B are part o� a single �unctional task. This is very good reason �or them to be contained in the same procedure.

Sequential CohesionModule A outputs some data which �orms the input to B. This is the reason �or them to be contained in the same procedure.


28

So�tware DesignProcedural CohesionProcedural Cohesion occurs in modules whose instructions although accomplish di��erent tasks yet have been combined because there is a speci�ic order in which the tasks are to be completed.

Temporal CohesionModule exhibits temporal cohesion when it contains tasks that are related by the �act that all tasks must be executed in the same time�span.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

29

So�tware DesignLogical CohesionLogical cohesion occurs in modules that contain instructions that appear to be related because they �all into the same logical class o� �unctions.Coincidental CohesionCoincidental cohesion exists in modules that contain instructions that have little or no relationship to one another.


30

So�tware DesignRelationship between Cohesion & CouplingI� the so�tware is not properly modularized, a host o� seemingly trivial enhancement or changes will result into death o� the project. There�ore, a so�tware engineer must design the modules with goal o� high cohesion and low coupling.�ig. 12 : View o� cohesion and couplingSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

31

So�tware DesignSTRATEGY O

� DESIGN

A good system design strategy is to organize the program modules in such a way that are easy to develop and latter to, change. Structured design techniques help developers to deal with the size and complexity o� programs. Analysts create instructions �or the developers about how code should be written and how pieces o� code should �it together to �orm a program. It is important �or two reasons: �irst, even pre�existing code, i� any, needs to be understood, organized and pieced together. Second, it is still common �or the project team to have to write some code and produce original programs that support the application logic o� the system.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

32

So�tware DesignBottom�Up DesignThese modules are collected together in the �orm o� a “library”.�ig. 13 : Bottom�up tree structureSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

33

So�tware DesignTop�Down DesignA top down design approach starts by identi�ying the major modules o� the system, decomposing them into their lower level modules and iterating until the desired level o� detail is achieved. This is stepwise re�inement; starting �rom an abstract design, in each step the design is re�ined to a more concrete level, until we reach a level where no more re�inement is needed and the design can be implemented directly.


34

So�tware DesignHybrid Design�or top�down approach to be e��ective, some bottom�up approach is essential �or the �ollowing reasons:To permit common sub modules. Near the bottom o� the hierarchy, where the intuition is simpler, and the need �or bottom�up testing is greater, because there are more number o� modules at low levels than high levels. In the use o� pre�written library modules, in particular, reuse o� modules.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

35

So�tware Design�UNCTION ORIENTED DESIGN�unction Oriented design is an approach to so�tware design where the design is decomposed into a set o� interacting units where each unit has a clearly de�ined �unction. Thus, system is designed �rom a �unctional viewpoint.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

36

So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

37

So�tware DesignWe continue the re�inement o� each module until we reach the statement level o� our programming language. At that point, we can describe the structure o� our program as a tree o� re�inement as in design top�down structure as shown in �ig. 14.�ig. 14 : Top�down structureSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

38

So�tware DesignI� a program is created top�down, the modules become very specialized. As one can easily see in top down design structure, each module is used by at most one other module, its parent.

�or a module, however, we must require that several othe

r modules as in design reusable structure as shown in �ig. 15.�ig. 15 : Design reusable structureSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

39

So�tware DesignDesign NotationsDesign notations are largely meant to be used during the process o� design and are used to represent design or design decisions.

�or a �unction oriented design,

the design can be represented graphically or mathematically by the �ollowing: Data �low diagrams Data Dictionaries Structure Charts PseudocodeSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

40

So�tware DesignStructure ChartIt partition a system into block boxes. A black box means that �unctionality is known to the user without the knowledge o� internal design.�ig. 16 : Hierarchical �ormat o� a structure chartSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

41

So�tware Design�ig. 17 : Structure chart notationsSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

42

So�tware DesignA structure chart �or “update �ile” is given in �ig. 18.�ig. 18 : Update �ileSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

43

So�tware DesignA transaction centered structure describes a system that processes a number o� di��erent types o� transactions. It is illustrated in �ig.19.�ig. 19 : Transaction�centered structureSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

44

So�tware DesignIn the above �igure the MAIN module controls the system operation its �unctions is to:invoke the INPUT module to read a transaction; determine the kind o� transaction and select one o� a number o� transaction modules to process that transaction, and output the results o� the processing by calling OUTPUT module.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

45

So�tware DesignPseudocodePseudocode notation can be used in both the preliminary and detailed design phases. Using pseudocode, the designer describes system characteristics using short, concise, English language phrases that are structured by key words such as It�Then�Else, While�Do, and End.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

46

So�tware Design�unctional Procedure Layers�unction are built in layers, Additional notation is used to speci�y details. Level 0

�unction or procedure name Relationship to other system components (e.g.,

part o� which system, called by which routines, etc.) Brie� description o� the �unction purpose. Author, date


47

So�tware DesignLevel 1

�unction Parameters (problem variables, types, purpose, etc.) Global var

iables (problem variable, type, purpose, sharing in�ormation) Routines called by the �unction Side e��ects Input/Output AssertionsSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

48

So�tware DesignLevel 2 Local data structures (variable etc.) Timing constraints Exception handling (conditions, responses, events) Any other limitations Level 3 Body (structured chart, English pseudo code, decision tables, �low charts, etc.)So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

49

So�tware DesignIEEE Recommended practice �or so�tware design descriptions (IEEE STD 1016�1998)ScopeAn SDD is a representation o� a so�tware system that is used as a medium �or communicating so�tware design in�ormation.Re�erencesi. IEEE std 830�1998, IEEE recommended practice �or so�tware requirements speci�ications. IEEE glossary o� so�twareii. IEEE std 610.12�1990, engineering terminology.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

50

So�tware DesignDe�initionsi. Design entity. An element (Component) o� a design that is structurally and �unctionally distinct �rom other elements and that is separately named and re�erenced.

ii. Design View. A subset o� design entity attribute in�ormation that is speci�ically suited to the needs o� a so�tware project activity. iii. Entity attributes. A named property or characteristics o� a design entity. It provides a statement o� �act about the entity. iv. So�tware design description (SDD). A representation o� a so�tware system created to �acilitate analysis, planning, implementation and decision making.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

51

So�tware DesignPurpose o� an SDDThe SDD shows how the so�tware system will be structured to satis�y the requirements identi�ied in the SRS. It is basically the translation o� requirements into a description o� the so�tware structure, so�tware components, inter�aces, and data necessary �or the implementation phase. Hence, SDD becomes the blue print �or the implementation activity.

Design Description In�ormation ContentIntroduction Design entities Design entity attributesSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

52

So�tware DesignThe attributes and associated in�ormation items are de�ined in the �ollowing subsections:

a) Identi�ication b) Type c) Purpose d) �unction e) Subordinates�)Dependencies

g) Inter�ace h) Resources i) j) Processing Data53


So�tware DesignDesign Description OrganizationEach design description writer may have a di��erent view o� what are considered the essential aspects o� a so�tware design. The organization o� SDD is given in table 1. This is one o� the possible ways to organize and �ormat the SDD. A recommended organization o� the SDD into separate design views to �acilitate in�ormation access and assimilation is given in table 2.


54

So�tware DesignCont…So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

55

So�tware DesignTable 1: Organization o� SDDSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

56

So�tware DesignDesign View Scope Entity attribute Identi�ication, type purpose, �unction, subordinate Example representation Hierarchical decomposition diagram, natural language Decomposition Partition o� the system into description design entities Dependency description Inter�ace description Description o� relationships among entities o� system resources List o� everything a designer, developer, tester needs to know to use design entities that make up the system Description o� the internal design details o� an entityIdenti�ication, type, Structure chart, data purpose, dependencies, �low diagrams, resources transaction diagrams Identi�ication, �unction, inter�aces Inter�ace �iles, parameter tablesDetail description

Identi�ication, processing, data�low charts, PDL etc.

Table 2: Design viewsSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

57

So�tware DesignObject Oriented DesignObject oriented design is the result o� �ocusing attention not on the �unction per�ormed by the program, but instead on the data that are to do manipulated by the program. Thus, it is orthogonal to �unction oriented design. Object Oriented Design begins with an examination o� the real world “things” that are part o� the problem to be solved. These things (which we will call objects) are characterized individually in terms o� their attributes and behavior.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

58

So�tware DesignBasic ConceptsObject Oriented Design is not dependent on any speci�ic implementation language. Problems are modeled using objects. Objects have:

Behavior (they do things) State (which changes when they do things)


59

So�tware DesignThe various terms related to object design are:

i.

Objects

The word “Object” is used very �requently and conveys di��erent meaning in di��erent circumstances. Here, meaning is an entity able to save a state (in�ormation) and which o��ers a number o� operations (behavior) to either examine or a��ect this state. An object is characterized by number o� operations and a state which remembers the e��ect o� these operations.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

60

So�tware Designii. MessagesObjects communicate by message passing. Messages consist o� the identity o� the target object, the name o� the requested operation and any other operation needed to per�orm the �unction. Message are o�ten implemented as procedure or �unction calls.

iii. AbstractionIn object oriented design, complexity is managed using abstraction. Abstraction is the elimination o� the irrelevant and the ampli�ication o� the essentials.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

61

So�tware Designiv. ClassIn any system, there shall be number o� objects. Some o� the objects may have common characteristics and we can group the objects according to these characteristics. This type o� grouping is known as a class. Hence, a class is a set o� objects that share a common structure and a common behavior. We may de�ine a class “car” and each object that represent a car becomes an instance o� this class. In this class “car”, Indica, Santro, Maruti, Indigo are instances o� this class as shown in �ig. 20. Classes are use�ul because they act as a blueprint �or objects. I� we want a new square we may use the square class and simply �ill in the particular details (i.e. colour and position) �ig. 21 shows how can we represent the square class.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

62

So�tware Design�ig.20: Indica, Santro, Maruti, Indigo are all instances o� the class “car”So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

63

So�tware Design�ig. 21: The square class


64

So�tware Designv. AttributesAn attributes is a data value held by the objects in a class. The square class has two attributes: a colour and array o� points. Each attributes has a value �or each object instance. The attributes are shown as second part o� the class as shown in �ig. 21.vi. OperationsAn operation is a �unction or trans�ormation that may be applied to or by objects in a class. In the square class, we have two operations: set colour() and draw(). All objects in a class share the same operations. An object “knows” its class, and hence the right implementation o� the operation. Operation are shown in the third part o� the class as indicated in �ig. 21.65


So�tware Designvii. InheritanceImagine that, as well as squares, we have triangle class.

�ig. 22 shows the clas

s �or a triangle.�ig. 22: The triangle classSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

66

So�tware DesignNow, comparing �ig. 21 and 22, we can see that there is some di��erence between triangle and squares classes.

�or example, at a high level o� abstraction, we mi

ght want to think o� a picture as made up o� shapes and to draw the picture, we draw each shape in turn. We want to eliminate the irrelevant details: we do not care that one shape is a square and the other is a triangle as long as both can draw themselves. To do this, we consider the important parts out o� these classes in to a new class called Shape.

�ig. 23 shows the results.


67

So�tware Design�ig. 23: Abstracting common �eatures in a new classThis sort o� abstraction is called inheritance. The low level classes (known as subclasses or derived classes) inherit state and behavior �rom this high level class (known as a super class or base class).So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

68

So�tware Designviii. PolymorphismWhen we abstract just the inter�ace o� an operation and leave the implementation to subclasses it is called a polymorphic operation and process is called polymorphism.

ix. Encapsulation (In�ormation Hiding)Encapsulation is also commonly re�erred to as “In�ormation Hiding”. It consists o� the separation o� the external aspects o� an object �rom the internal implementation details o� the object.x.

Hierarchy

Hierarchy involves organizing something according to some particular order or rank. It is another mechanism �or reducing the complexity o� so�tware by being able to treat and express sub�types in a generic way.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

69

So�tware Design�ig. 24: Hierarchy


70

So�tware DesignSteps to Analyze and Design Object Oriented SystemThere are various steps in the analysis and design o� an object oriented system and are given in �ig. 25So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

71

So�tware Design�ig. 25: Steps �or analysis & design o� object oriented system


72

So�tware Designi. Create use case model�irst step is to identi�y the actors interacting with the system. We should then write the use case and draw the use case diagram.

ii.

Draw activity diagram (I� required)Activity Diagram illustrate the dynamic nature o� a system by modeling the �low o� control �orm activity to activity. An activity represents an operation on some class in the system that results in a change in the state o� the system. �ig. 26 shows the activity diagram processing an order to deliver some goods.


73

So�tware Design�ig. 26: Activity diagramSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

74

So�tware Designiii. Draw the interaction diagramAn interaction diagram shows an interaction, consisting o� a set o� objects and their relationship, including the messages that may be dispatched among them. Interaction diagrams address the dynamic view o� a system.Steps to draws interaction diagrams are as under:a) b) d)

�irstly, we should identi�y that the objects with respects to every use

case. We draw the sequence diagrams �or every use case. We draw the collaboration diagrams �or every use case.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

75

So�tware DesignThe object types used in this analysis model are entity objects, inter�ace objects and control objects as given in �ig. 27.�ig. 27: Object types


76

So�tware Designiv. Draw the class diagramThe class diagram shows the relationship amongst classes. There are �our types o� relationships in class diagrams.a)

Association are semantic connection between classes. When an association connects two classes, each class can send messages to the other in a sequence or a collaboration diagram. Associations can be bi�directional or unidirectional.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

77

So�tware Designb) Dependencies connect two classes. Dependencies are always unidirectional and show that one class, depends on the de�initions in another class.c)

Aggregations are stronger �orm o� association. An aggregation is a relationship between a whole and its parts.

d)

Generalizations are used to show an inheritance relationship between two classes.


78

So�tware Designv. Design o� state chart diagramsA state chart diagram is used to show the state space o� a given class, the event that cause a transition �rom one state to another, and the action that result �rom a state change. A state transition diagram �or a “book” in the library system is given in �ig. 28.�ig. 28: Transition chart �or “book” in a library system.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

79

So�tware Designvi. Draw component and development diagramComponent diagrams address the static implementation view o� a system they are related to class diagrams in that a component typically maps to one or more classes, inter�aces or collaboration. Deployment Diagram Captures components and the hardware. relationship between physical


80

So�tware DesignA so�tware has to be developed �or automating the manual library o� a University. The system should be stand alone in nature. It should be designed to provide �unctionality’s as explained below: Issue o� Books: A student o� any course should be able to get books issued. Books �rom General Section are issued to all but Book bank books are issued only �or their respective courses. A limitation is imposed on the number o� books a student can issue. A maximum o� 4 books �rom Book bank and 3 books �rom General section is issued �or 15 days only.The so�tware takes the current system date as the date o� issue and calculates date o� return.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

81

So�tware DesignA bar code detector is used to save the student as well as book in�ormation. The due date �or return o� the book is stamped on the book. Return o� Books: Any person can return the issued books. The student in�ormation is displayed using the bar code detector. The system displays the student details on whose name the books were issued as well as the date o� issue and return o� the book. The system operator veri�ies the duration �or the issue. The in�ormation is saved and the corresponding updating take place in the database.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

82

So�tware DesignQuery Processing: The system should be able to provide in�ormation like: Availability o� a particular book. Availability o� book o� any particular author. Number o� copies available o� the desired book. The system should also be able to generate reports regarding the details o� the books available in the library at any given time. The corresponding printouts �or each entry (issue/return) made in the system should be generated. Security provisions like the ‘login authenticity should be provided. Each user should have a user id and a password. Record o� the users o� the system should be kept in the log �ile. Provision should be made �or �ull backup o� the system.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

83


84


85


86


87


88


89


90


91


92


93

Multiple Choice QuestionsNote: Choose most appropriate answer o� the �ollowing questions:5.1 The most desirable �orm o� coupling is (a) Control Coupling (b) Data Coupling (c) Common Coupling (d) Content Coupling 5.2 The worst type o� coupling is (a) Content coupling (c) External coupling (b) Common coupling (d) Data coupling

5.3 The most desirable �orm o� cohesion is (a) Logical cohesion (b) Procedural cohesion (c)

�unctional cohesion (d) Temporal cohesion 5.4 The worst type o� cohe

sion is (a) Temporal cohesion (c) Logical cohesion (b) Coincidental cohesion (d) Sequential cohesion

5.5 Which one is not a strategy �or design? (a) Bottom up design (b) Top down design (c) Embedded design (d) Hybrid designSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

94

Multiple Choice Questions5.6 Temporal cohesion means (a) Cohesion between temporary variables (b) Cohesion between local variable (c) Cohesion with respect to time (d) Coincidental cohesion 5.7

�unctional cohesion means (a) Operations are part o� single �unctional

task and are placed in same procedures (b) Operations are part o� single �unctional task and are placed in multiple procedures (c) Operations are part o� multiple tasks (d) None o� the above 5.8 When two modules re�er to the same global data area, they are related as (a) External coupled (b) Data coupled (c) Content coupled (d) Common coupled 5.9 The module in which instructions are related through �low o� control is (a) Temporal cohesion (b) Logical cohesion (c) Procedural cohesion (d)

�unctional cohesion

95


Multiple Choice Questions5.10 The relationship o� data elements in a module is called (a) Coupling (b) Cohesion (c) Modularity (d) None o� the above 5.11 A system that does not interact with external environment is called (a) Closed system (b) Logical system (c) Open system (d) Hierarchal system 5.12 The extent to which di��erent modules are dependent upon each other is called (a) Coupling (b) Cohesion (c) Modularity (d) Stability


96

Exercises5.1 What is design? Describe the di��erence between conceptual design and technical design. 5.2 Discuss the objectives o� so�tware design. How do we trans�orm an in�ormal design to a detailed design? 5.3 Do we design so�tware when we “write” a program? What makes so�tware design di��erent �rom coding? 5.4 What is modularity? List the important properties o� a modular system. 5.5 De�ine module coupling and explain di��erent types o� coupling. 5.6 De�ine module cohesion and explain di��erent types o� cohesion. 5.7 Discuss the objectives o� modular so�tware design. What are the e��ects o� module coupling and cohesion? 5.8 I� a module has logical cohesion, what kind o� coupling is this module likely to have with others? 5.9 What problems are likely to arise i� two modules have high coupling?So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

97

Exercises5.10 What problems are likely to arise i� a module has low cohesion? 5.11 Describe the various strategies o� design. Which design strategy is most popular and practical? 5.12 I� some existing modules are to be re�used in building a new system, which design strategy is used and why? 5.13 What is the di��erence between a �low chart and a structure chart? 5.14 Explain why it is important to use di��erent notations to describe so�tware designs. 5.15 List a �ew well�established �unction oriented so�tware design techniques. 5.16 De�ine the �ollowing terms: Objects, Message, Abstraction, Class, Inheritance and Polymorphism. 5.17 What is the relationship between abstract data types and classes?So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

98

Exercises5.18 Can we have inheritance without polymorphism? Explain. 5.19 Discuss the reasons �or improvement using object�oriented design. 5.20 Explain the design guidelines that can be used to produce “good quality” classes or reusable classes. 5.21 List the points o� a simpli�ied design process. 5.22 Discuss the di��erences between object oriented and �unction oriented design. 5.23 What documents should be produced on completion o� the design phase? 5.24 Can a system ever be completely “decoupled”? That is, can the degree o� coupling be reduced so much that there is no coupling between modules?


99


1

So�tware MetricsSo�tware Metrics: What and Why ?1. How to measure the size o� a so�tware? 2. How much will it cost to develop a so�tware? 3. How many bugs can we expect? 4. When can we stop testing? 5. When can we release the so�tware?So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

2

So�tware Metrics6. What is the complexity o� a module? 7. What is the module strength and coupling? 8. What is the reliability at the time o� release? 9. Which test technique is more e��ective? 10. Are we testing hard or are we testing smart? 11. Do we have a strong program or a week test suite?


3

So�tware MetricsPressman explained as “A measure provides a quantitative indication o� the extent, amount, dimension, capacity, or size o� some attribute o� the product or process”. Measurement is the act o� determine a measure The metric is a quantitative measure o� the degree to which a system, component, or process possesses a given attribute.

�enton de�ined measurement as “ it is the process by which numbers or sym

bols are assigned to attributes o� entities in the real world in such a way as to describe them according to clearly de�ined rules”.So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

4

So�tware MetricsDe�initionSo�tware metrics can be de�ined as “The continuous application o� measurement based techniques to the so�tware development process and its products to supply meaning�ul and timely management in�ormation, together with the use o� those techniques to improve that process and its products”.


5

So�tware MetricsAreas o� ApplicationsThe most established area o� so�tware metrics is cost and size estimation techniques. The prediction o� quality levels �or so�tware, o�ten in terms o� reliability, is another area where so�tware metrics have an important role to play. The use o� so�tware metrics to provide quantitative checks on so�tware design is also a well established area.


6

So�tware MetricsProblems During ImplementationStatement : So�tware development is to complex; it cannot be managed like other parts o� the organization. : �orget it, we will �ind developers and managers who will manage that development. : I am only six months late with project. :

�ine,

you are only out o� a job.Management view

Statement Management view


7

So�tware MetricsStatement Management view Statement Management view : I am only six months late with project. :

�ine, you are only out o� a job. : But you cannot put reliabilit

y constraints in the contract. : Then we may not get the contract.


8

So�tware MetricsCategories o� Metricsi. Product metrics: describe the characteristics o� the product such as size, complexity, design �eatures, per�ormance, e��iciency, reliability, portability, etc. ii. Process metrics: describe the e��ectiveness and quality o� the processes that produce the so�tware product. Examples are:• • • • • e��ort required in the process time to produce the product e��ectiveness o� de�ect removal during development number o� de�ects �ound during testing maturity o� the processSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

9

So�tware Metricsii. Project metrics: describe the project characteristics and execution. Examples are :• • • • number o� so�tware developers sta��ing pattern over the li�e cycle o� the so�tware cost and schedule productivity


10

So�tware MetricsToken CountThe size o� the vocabulary o� a program, which consists o� the number o� unique tokens used to build a program is de�ined as: η = η1 + η2 η : vocabulary of a program were η1 : number of unique operators η2 : number of unique operands

Software Engineering (3rd ed.), By K.K Aggarwal & Yoges Sing

, Copyrig

t © New Ag

e International Publisers, 2007

11

Software MetricsTe lengt

of t

e program in t

e terms of t

e total number of tokens used is

N = N1+N2 N : program lengt were N1 : total occurrences of operators N2 : tota

l occurrences of operands


, Copyrig

t © New Ag


12

Software MetricsVolume V = N * log2 η T

e unit of measurement of volume is t

e common unit for siz

e “bits”. It is te actual size of a program if a uniform binary encoding for t

e vo

cabulary is used. Program Level L = V* / V Te value of L ranges between zero an

d one, wit L=1 representing a program written at t

e igest possible level (i.

e., wit minimum size).


, Copyrig

t © New Ag


13

Software MetricsProgram Difficulty D=1/L As t

e volume of an implementation of a program increas

es, te program level decreases and t

e difficulty increases. T

us, programming

practices suc as redundant usage of operands, or t

e failure to use

iger-leve

l control constructs will tend to increase te volume as well as t

e difficulty.

Effort E=V/L=D*V Te unit of measurement of E is elementary mental discriminati

ons.Software Engineering (3rd ed.), By K.K Aggarwal & Yoges

Sing

, Copyrig

t © New Ag


14

Software MetricsEstimated Program Lengt

Ν = η 1 log 2 η 1 + η 2 log 2 η 2∧

∧

Ν = 14 log 2 14 + 10 log 2 10= 53.34 + 33.22 = 86.56 T

e following alternate expressions

ave been publis

ed

to estimate program lengt.

Ν J = Log 2 (η 1!) + log 2 (η 2 !)Software Engineering (3rd ed.), By K.K Aggarwal & Yoges

Sing

, Copyrig

t ©

ew Ag


15

Software MetricsΝ B = η1 Log 2η 2 + η 2 log 2 η1Ν c = η1 η1 + η 2 η 2

Ν s = (η log 2 η ) / 2Te definitions of unique operators, unique operands, total operators and total

operands are not specifically delineated.


, Copyrig

t ©

ew Ag


16

Software MetricsCounting rules for C language1. Comments are not considered. 2. T

e identifier and function declarations are

not considered. 3. All te variables and constants are considered operands. 4. G

lobal variables used in different modules of te same program are counted as mul

tiple occurrences of te same variable.


, Copyrig

t ©

ew Ag


17

Software Metrics5. Local variables wit

te same name in different functions are counted as uniq

ue operands. 6. Functions calls are considered as operators. 7. All looping statements e.g., do {…} w

ile ( ), w

ile ( ) {…}, for ( ) {…}, all control statements e.g.

, if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators. 8. In control construct switc

( ) {case:…}, switc

as well as all t

e case statements are consider

ed as operators.


, Copyrig

t ©

ew Ag


18

Software Metrics9. T

e reserve words like return, default, continue, break, sizeof, etc., are co

nsidered as operators. 10. All te brackets, commas, and terminators are conside

red as operators. 11. GOTO is counted as an operator and te label is counted as

an operand. 12. Te unary and binary occurrence of “+” and “-” are dealt separately. Si

milarly “*” (multiplication operator) are dealt wit separately.


, Copyrig

t ©

ew Ag


19

Software Metrics13. In t

e array variables suc

as “array-name [index]” “arrayname” and “index” are consider

ed as operands and [ ] is considered as operator. 14. In te structure variables

suc as “struct-name, member-name” or “struct-name -> member-name”, struct-name, member

-name are taken as operands and ‘.’, ‘->’ are taken as operators. Some names of member elements in different structure variables are counted as unique operands. 15. All te as directive are ignored.


, Copyrig

t ©

ew Ag


20

Software MetricsPotential Volume

V * = (2 + η ) log 2 (2 + η )Estimated Program Level / Difficulty∧

* 2

* 2

Halstead offered an alternate formula tat estimate t

e program level.

∧

L = 2η 2 /(η1Ν 2 )were

η1Ν 2 D= ∧ = L 2η 2∧

1


, Copyrig

t ©

ew Ag


21

Software MetricsEffort and Time∧ ∧

Ε =V / L =V *D

= (n1 N 2 N log 2 η ) / 2η 2

T = �/β

β is normally set to 18 since tis seemed to give

�est results in Halstead’s earlies

t experiments, wic compared t

e predicted times wit

o�served programming time

s, including te time for design, coding, and testing.

Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges

Sing

, Copyrig

t © New Ag

e International Pu�lis

ers, 2007

22

Software MetricsLanguage Level

λ = L ×V * = L VUsing this formu�a, Ha�stead and other researchers determined the �anguage �eve� for various �anguages as shown in Tab�e 1.2

Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200723

Software Metrics

Tab�e 1: Language �eve�sSoftware Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200724

Software MetricsExamp�e- 6.I Consider the sorting program in Fig. 2 of chapter 4. List out the operators and operands and a�so ca�cu�ate the va�ues of software science measures �ike η , N , V , � , λetc.


Software Metrics

Tab�e 2: Operators and operands of sorting program of fig. 2 of chapter 4Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200727

Software MetricsHere N1=53 and N2=38. The program �ength N=N1+N2=91 Vocabu�ary of the program η Volume

= η1 + η 2 = 14 + 10 = 24

V = N × log 2 η= 91 x log224 = 417

�its

∧

Te estimated program lengt

N

of te program

= 14 log214 + 10 log210 = 14 * 3.81 + 10 * 3.32 = 53.34 + 33.2 = 86.45Software

�ngineering (3rd ed.), By K.K Aggarwal & Yoges

Sing

, Copyrig

t © New Ag


ers, 2007

28

Software MetricsConceptually unique* 2

input

and

output

parameters

are

represented �y η

* η 2 = 3 {x: array olding t

e integer to

�e sorted. T

is is used�

ot as input and output}.

{N: te size of t

e array to

�e sorted}. T

e potential volume V* = 5 log25 = 11.

6 Since L = V* / V


Sing

, Copyrig

t © New Ag


ers, 2007

29

Software Metrics11.6 = = 0.027 417D=I/L

1 = = 37.03 0.027�stimated program level

2 10 L= × = × = 0.038 η1 N 2 14 38Software


Sing

, Copyrig

t © New Ag


ers, 2007

∧

2

η2

30

Software MetricsWe may use anot

er formula

∧ ∧

V = V × L = 417 × 0.038 = 15.67∧ ∧ ∧� = V / L = D× V=417 / 0.038 = 10973.68 T

erefore, 10974 elementary mental discrimination are re

quired to construct te program.

10974 T = �/β = = 610 seconds = 10 minutes 18

Tis is pro

�a�ly a reasona

�le time to produce t

e program, w

ic is very simple


Sing

, Copyrig

t © New Ag


ers, 2007

31

Software Metrics

Ta�le 3


Sing

, Copyrig

t © New Ag


ers, 2007

32

Software Metrics

Ta�le 3


Sing

, Copyrig

t © New Ag


ers, 2007

33

Software Metrics�xample- 6.2 Consider t

e program s

own in Ta

�le 3. Calculate t

e various softwa

re science metrics.


Sing

, Copyrig

t © New Ag


ers, 2007

34

Software MetricsSolution List of operators and operands are given in Ta

�le 4.

Ta�le 4


Sing

, Copyrig

t © New Ag


ers, 2007

35

Software Metrics

Ta�le 5


Sing

, Copyrig

t © New Ag


ers, 2007

36

Software MetricsProgram voca

�ulary Program lengt

η = 42N = N1 +N2∧

= 84 + 55 = 139 = 24.91�stimated lengt

% error Program volume

N = 24 log 2 24 + 18 log 2 18 = 185.115V = 749.605

�its�

stimated program level

=

2

η1

×

η2N2

2 18 = × = 0.02727 24 55Software


Sing

, Copyrig

t © New Ag


ers, 2007

37

Software MetricsMinimal volume V*=20.4417∧�ffort

=V / L

748.605 = .02727= 27488.33 elementary mental discriminations. Time T =

27488.33 �/β = 18

= 1527.1295 seconds = 25.452 minutesSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

38

Software MetricsData Structure MetricsProgram Data Input Internal Data Data Output

Payroll

Name/ Social Security Wit

olding rates No./ Pay Rate/ Num�er Overtime factors o

f ours worked Insurance premium Rates Item Names/ Item amounts/ Relations

ips a

mong items Program size/ No. of software developers on team Cell computations Su�-totals

Gross pay wit

olding Net pay Pay ledgers Spreadseet of items and totals

Spreadseet

Software Planner

Model parameters Constants Coefficients�st. project effort

�st. project duration

Fig.1: Some examples of input, internal, and output dataSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

39

Software MetricsTe Amount of Data

One metod for determining t

e amount of data is to count t

e num

�er of entries

in te cross-reference list. A varia

�le is a string of alp

anumeric c

aracters t

at is defined �y a developer and t

at is used to represent some value during ei

ter compilation or execution.


Sing

, Copyrig

t © New Ag


ers, 2007

40

Software Metrics

Fig.2: Payday programSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

41

Software Metricsceck gross

ours net pay 2 4 6 4 5 14 rate tax 6 4 12 11 14 12 14 11 13 13 12 1

5 13 15 12 14 15 13 15 14 15 14 15

Fig.3: A cross reference of program paydaySoftware


Sing

, Copyrig

t © New Ag


ers, 2007

42

Software Metricsfeof stdin 9 10

Fig.4: Some items not counted as VARS

η2

= VARS + unique constants + la�els.

Halstead introduced a metric tat

e referred to as la

�els. T

us,

of te operands in a program – including all varia

�les, constants, and

η2

to �e a count

η 2 = VARS + unique constants + la�els


Sing

, Copyrig

t © New Ag


ers, 2007

43

Software Metrics

Fig.6: Program payday wit operands in

�rackets


Sing

, Copyrig

t © New Ag


ers, 2007

44

Software MetricsTe Usage of Data wit

in a Module

Live Varia�les Definitions :

1. A varia�le is live from t

e �eginning of a procedure to t

e end of t

e proced

ure. 2. A varia�le is live at a particular statement only if it is referenced a

certain num�er of statements

�efore or after t

at statement. 3. A varia

�le is li

ve from its first to its last references witin a procedure.


Sing

, Copyrig

t © New Ag


ers, 2007

45

Software Metrics


Sing

, Copyrig

t © New Ag


ers, 2007

cont… 46

Software Metrics

Fig.6: Bu��

le sort programSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

47

Software MetricsIt is t

us possi

�le to define t

e average num

�er of live varia

�les,

(LV ) wic is t

e sum of t

e count of live varia

�les divided

�y

te count of executa

�le statements in a procedure. T

is is a complexity measure

for data usage in a procedure or program. Te live varia

�les in t

e program in f

ig. 6 appear in fig. 7 te average live varia

�les for t

is program is

124 = 3.647 34Software


Sing

, Copyrig

t © New Ag


ers, 2007

48

Software MetricsLine4 5 6 7 8 9 10 11 12 13 14 15 16

Live Varia�les

------t, x, k t, x, k t, x, k ---------------size size, j Size, j, a, �

Count0 0 3 3 3 0 0 0 0 0 1 2 4


Sing

, Copyrig

t © New Ag


ers, 2007

cont…

49


Live Varia�les

size, j, a, �, last size, j, a,

�, last, continue size, j, a,

�, last, continue

size, j, a, �, last, continue size, j, a,

�, last, continue size, j, a,

�, last,

continue size, j, a, �, last, continue, i size, j, a,

�, last, continue, i size

, j, a, �, continue, i size, j, a,

�, continue, i size, j, a,

�, continue, i siz

e, j, a, �, continue, i size, j, a,

�, i

Count5 6 6 6 6 6 7 7 6 6 6 6 5


Sing

, Copyrig

t © New Ag


ers, 2007

cont…

50

Software MetricsLine30 31 32 33 34 35 36 37

Live Varia�les

size, j, a, �, i size, j, a,

�, i size, j, a,

�, i size, j, a,

� size, j, a,

� s

ize, j, a, � j, a,

� --

Count5 5 5 4 4 4 3 0

Fig.7: Live varia�les for t

e program in fig.6


Sing

, Copyrig

t © New Ag


ers, 2007

51

Software MetricsVaria

�le spans

… 21 … 32 … 45 … 53 … 60 … scanf (“%d %d, &a, &�) x =a; y = a –

�; z = a; printf (“%d %d, a,

Fig.: Statements in ac program referring to varia�les a and

�.

Te size of a span indicates t

e num

�er of statements t

at pass

�etween successi

ve uses of a varia�les


Sing

, Copyrig

t © New Ag


ers, 2007

52

Software MetricsMaking program-wide metrics from intra-module metricsFor example if we want to c

aracterize t

e average num

�er of live varia

�les for

a program aving modules, we can use t

is equation.

m

LV program =

i =1

Σ LVi m

where ( LV ) i is the average live variable metric computed from the ith module The average span size (

�P) for a program of n spans could be computed by using t

he equation.n i =1�P program =

Σ �Pi n

53�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



�oftware MetricsProgram WeaknessA program consists of modules. Using the average number of live variables (LV ) and average life variables (γ ) , the module weakness has been defined as

WM = LV * γ

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


54

Software MetricsA pro

ram is normally a combination of various modules, hence pro

ram weakness c

an be a useful measure and is defined as:

�m � � iΣ WM i � � =1 � WP = mwhere, WMi WP m : weakness of ith module : weakness of the program : number of modules in the program�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh



55

�oftware MetricsExample- 6.3 Consider a program for sorting and searching. The program sorts an array using selection sort and than search for an element in the sorted array. The program is given in fig. 8. Generate cross reference list for the program and also calculate andγ WM for the LV , , pro

ram.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


56

Software MetricsSolution The

iven pro

ram is of 66 lines and has 11 variables. The variables ar

e a, I, j, item, min, temp, low, hi h, mid, loc and option.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


57

Software Metrics

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


58

Software Metrics

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


59

Software Metrics

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


60

Software Metrics

Fi .8: Sortin

& searchin

pro

ram

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


61

Software MetricsCross-Reference list of the pro

ram is

iven below:

a i j item min temp low hi h mid loc option 11 12 12 12 12 12 13 13 13 13 14 18

16 25 44 24 29 46 45 46 56 40 19 16 25 47 27 31 47 46 47 61 41 50 47 49 62 52 51 50 54 52 51 54 52 59 61 27 16 25 49 29 27 18 27 59 30 29 19 30 62 30 22 31 30 22 31 22 37 24 47 36 49 36 59 36 37 37

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


62

Live Variables per line are calculated as:Line13 14 15 16 17 18 19 20 22 23 24 25 26

Live Variableslow low low low, i low, i low, i, a low, i, a low, i, a low, i, a low, i, a low, i, a, min low, i, a, min, j low, i, a, min, j

Count1 1 1 2 2 3 3 3 3 3 4 5 5

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


cont… 63


Live Variableslow, i, a, min, j low, i, a, min, j low, i, a, min, j, temp low, i, a, min, j, temp low, i, a, j, temp low, i, a low, i, a low, i, a low, i, a low, i, a low, i, a low, a low, a

Count5 5 6 6 5 3 3 3 3 3 3 2 2

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


cont… 64


Live Variableslow, a, option low, a, option low, a low, a low, a, item low, a, item, hi

h low,

a, item, hi h, mid low, a, item, hi

h, mid low, a, item, hi

h, mid low, a, item

, hi h, mid low, a, item, hi



h,

mid

Count3 3 2 2 3 4 5 5 5 5 5 5 5

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


cont… 65

Software MetricsLine53 54 55 56 57 58 59 60 61 62

Live Variableslow, a, item, hi


h, mid a, item, mid a, item, mid, loc a

, item, mid, loc a, item, mid, loc a, item, mid, loc item, mid, loc item, mid, loc item, loc

Count5 5 3 4 4 4 4 3 3 2

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


cont… 66

Software MetricsLine63 64 65 66 Total

Live Variables

Count0 0 0 0 174

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


67

Software MetricsAvera

e number of live variables (LV) =

Sum of count of live variables Count of executable statements

174 = 3 . 28 53 Sum of count of live variables γ = Total number of variables 174 γ = = 15 . 8 11 Module Weakness (WM) = LV × γ LV = WM = 3 . 28 × 15 . 8 = 51 . 8

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


68

Software MetricsThe Sharin

of Data Amon

Modules

A pro ram normally contains several modules and share couplin

amon

modules. Ho

wever, it may be desirable to know the amount of data bein shared amon

the mod

ules.

Fi .10: Three modules from an ima

inary pro

ram

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


69

Software Metrics

Fi .11: ”Pipes” of data shared amon

the modules

Fi .12: The data shared in pro

ram bubble

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


70

Software MetricsInformation Flow MetricsComponent : Any element identified by decomposin

a (software) system into its c

onstituent parts. : The de ree to which a component performs a sin

le function.

: The term used to describe the de ree of linka

e between one component to other

s in the same system.

Cohesion

Couplin

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


71

Software MetricsThe Basic Information Flow ModelInformation Flow metrics are applied to the Components of a system desi

n. Fi

.

13 shows a fra ment of such a desi

n, and for component ‘A’ we can define three meas

ures, but remember that these are the simplest models of IF. 1. ‘FAN IN’ is simply a count of the number of other Components that can call, or pass control, to Component A. 2. ‘FANOUT’ is the number of Components that are called by Component A. 3. This is derived from the first two by usin

the followin

formula. We will call

this measure the INFORMATION FLOW index of Component A, abbreviated as IF(A). IF(A) = [FAN IN(A) x FAN OUT (A)]2Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


72

Software Metrics

Fi .13: Aspects of complexity

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


73

Software MetricsThe followin

is a step-by-step

uide to derivin

these most simple of IF metric

s. 1. Note the level of each Component in the system desi n. 2. For each Compone

nt, count the number of calls so that Component – this is the FAN IN of that Component. Some or

anizations allow more than one Component at the hi

hest level in t

he desi n, so for Components at the hi

hest level which should have a FAN IN of

zero, assi n a FAN IN of one. Also note that a simple model of FAN IN can penali

ze reused Components. 3. For each Component, count the number of calls from the Component. For Component that call no other, assi

n a FAN OUT value of one. cont…

74Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Software Metrics4. Calculate the IF value for each Component usin

the above formula. 5. Sum the

IF value for all Components within each level which is called as the LEVEL SUM. 6. Sum the IF values for the total system desi

n which is called the SYSTEM SUM

. 7. For each level, rank the Component in that level accordin to FAN IN, FAN O

UT and IF values. Three histo rams or line plots should be prepared for each lev

el. 8. Plot the LEVEL SUM values for each level usin a histo

ram or line plot.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


75

Software MetricsA More Sophisticated Information Flow Modela = the number of components that call A. b = the number of parameters passed to A from components hi

her in the hierarchy. c = the number of parameters passed

to A from components lower in the hierarchy. d = the number of data elements read by component A. Then: FAN IN(A)= a + b + c + d

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


76

Software MetricsAlso let: e = the number of components called by A; f = the number of parameters passed from A to components hi

her in the hierarchy;

= the number of paramete

rs passed from A to components lower in the hierarchy; h = the number of data elements written to by A. Then: FAN OUT(A)= e + f +

+ h

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


77

Object Oriented MetricsTerminolo

ies

S.No 1 Term Object Meanin /purpose Object is an entity able to save a state (inf

ormation) and offers a number of operations (behavior) to either examine or affect this state. A request that an object makes of another object to perform an operation. A set of objects that share a common structure and common behavior manifested by a set of methods; the set serves as a template from which object can be created. an operation upon an object, defined as part of the declaration of a class. Defines the structural properties of a class and unique within a class. An action performed by or on an object, available to all instances of class, need not be unique.78

2 3

Messa e Class

4 5 6

Method Attribute Operation

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Object Oriented MetricsTerminolo

ies

S.No 7 8 Term Meanin /purpose Instantiation The process of creatin

an instance

of the object and bindin or addin

the specific data. Inheritance A relationshi

p amon classes, where in an object in a class acquires characteristics from one

or more other classes. The de ree to which the methods within a class are relat

ed to one another. Object A is coupled to object B, if and only if A sends a messa e to B.

9 10

Cohesion Couplin

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


79

Object Oriented Metrics• Measurin

on class level – couplin

– inheritance – methods – attributes – cohesion • Meas

in on system level

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


80

Object Oriented MetricsSize Metrics: Number of Methods per Class (NOM) Number of Attributes per Class (NOA) • Wei

hted Number Methods in a Class (WMC) – Methods implemented within a class

or the sum of the complexities of all methods

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


81

Object Oriented MetricsCouplin

Metrics: • Response for a Class (RFC ) – Number of methods (internal and ex

ternal) in a class.

Data Abstraction Couplin (DAC) - Number of Abstract Data Types in a class.

Couplin between Objects (CBO) – Number of other classes to which it is coupled.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


82

Object Oriented Metrics• Messa

e Passin

Couplin

(MPC) – Number of send statements defined in a class.

• Couplin Factor (CF) – Ratio of actual number of couplin

in the system to the max

. possible couplin .

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


83

Object Oriented MetricsCohesion Metrics: LCOM: Lack of cohesion in methods – Consider a class C1 with n methods M1, M2…., Mn. Let (Ij) = set of all instance variables used by method Mi. There are n such sets {I1},…….{In}. Let

P = {(Ii , I j ) | Ii ∩ I j = 0} and Q = {((Ii , I j ) | Ii ∩ I j ≠ 0}If all n {( I 1 },........ .(I n )} sets are 0 then P=0

LCOM =| P | - | Q |, if | P | > | Q | = 0 otherwise

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


84

Object Oriented Metrics• Ti

ht Class Cohesion (TCC)

_ with Percenta e of pairs of public methods of the class common attribute usa

e

.

• Loose Class Cohesion (LCC) – Same as TCC except that this metric consider indirectly connected methods. • Information based Cohesion (ICH) – Number of invocations of other methods of the same class, wei

hted by the number of parameters of the inv

oked method.Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


also

85

Object Oriented MetricsInheritance Metrics:

•

DIT - Depth of inheritance tree

•

NOC - Number of children – only immediate subclasses are counted.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


86

Object Oriented MetricsInheritance Metrics: • AIF- Attribute Inheritance Factor – Ratio of the sum of inherited attributes in all classes of the system to the total number of attributes for all classes.

AIF =

∑ ∑

TC i =1 TC

A d (C i ) A a (C i )

i =1

Aa(Ci ) = Ai(Ci ) + Ad (Ci )TC= total number of classes Ad (Ci) = number of attribute declared in a class Ai (Ci) = number of attribute inherited in a classSoftware En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


87

Object Oriented MetricsInheritance Metrics: • MIF- Method Inheritance Factor – Ratio of the sum of inherited methods in all classes of the system to the total number of methods for all classes.

∑ MIF = ∑

TC i =1 TC

Mi(C i) Ma(C i)

i =1

M a(C i) = M i(C i) + M d(C i)TC= total number of classes Md(Ci)= the number of methods declared in a class Mi(Ci)= the number of methods inherited in a classSoftware En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


88

UseUse-Case Oriented Metrics• Countin

actors

Type Simple Avera e Complex Description Pro

ram interface Interactive or protoco

l driven interface Graphical interface Factor 1 2 3

Actor wei htin

factors o o o Simple actor: represents another system with a def

ined interface. Avera e actor: another system that interacts throu

h a text base

d interface throu h a protocol such as TCP/IP. Complex actor: person interactin

throu

h a GUI interface.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


The actors wei ht can be calculated by addin

these values to

ether.

89

UseUse-Case Oriented Metrics• Countin

use cases

Type Simple Avera e Complex Description 3 or fewer transactions 4 to 7 transacti

ons More than 7 transactions Factor 5 10 15

Transaction-based wei htin

factors The number of each use case type is counted

in the software and then each number is multiplied by a wei htin

factor as show

n in table above.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


90

Web En ineerin

Project Metrics

Number of static web pa es Number of dynamic web pa

es Number of internal pa

e l

inks Word count Web pa e similarity Web pa

e search and retrieval Number of stat

ic content objects Number of dynamic content objects

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


91

Metrics AnalysisStatistical Techniques • • • • • Summary statistics such as mean, median, max. and min. Graphical representations such as histo

rams, pie charts and box plots. Principal

component analysis Re ression and correlation analysis Reliability models for pr

edictin future reliability.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


92

Metrics AnalysisProblems with metric data: • • • • Normal Distribution Outliers Measurement Scale Multicollinearity

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


93

Metrics AnalysisCommon pool of data: • • • The selection of projects should be representative and not all come from a sin

le application domain or development styles. No sin

le very

lar e project should be allowed to dominate the pool. For some projects, certain

metrics may not have been collected.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


94

Metrics AnalysisPattern of Successful Applications: • • • • • • • • Any metric is better then none. Automatis essential. Empiricism is better then theory. Use multifactor rather then sin

l

e metrics. Don’t confuse productivity metrics with complexity metrics. Let them mature. Maintain them. Let them die.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


95

Multiple Choice QuestionsNote: Choose most appropriate answer of the followin

questions:

6.1 Which one is not a cate ory of software metrics ? (a) Product metrics (b) Pr

ocess metrics (c) Project metrics (d) People metrics 6.2 Software science measures are developed by (a) M.Halstead (b) B.Littlewood (c) T.J.McCabe (d) G.Rothermal 6.3 Vocabulary of a pro

ram is defined as:

(a )η = η1 + η 2 (c)η = η1 ×η 2

(�)η = η1 − η 2 (d )η = η1 / η 2

6.4 In alstead t

eory of software science, volume is measured in

�its. T

e �its

are (a) Num�er of

�its required to store t

e program (

�) Actual size of a progr

am if a uniform �inary encoding sc

eme for voca

�ulary is used (c) Num

�er of

�its

required to execute te program (d) None ofSoftware

�ngineering (3 ed.), By K.K

Aggarwal & Yoges Sing

, Copyrig

t © New Age International Pu

�lis

ers, 2007 t

e a�

overd

96

Multiple Coice Questions

6.5 In Halstead teory, effort is measured in (a) Person-mont

s (

�) Hours (c)

�l

ementary mental discriminations (d) None of te a

�ove 6.6 Language level is defi

ned as

(a ) λ = L3V (c) λ = LV *6.7 Program weakness is

(b) λ = LV(d ) λ = L2V(b) WM = LV / γ(d) None of the above

(a) WM = LV × γ (a) WM = LV + γ

6.8 ‘FAN IN’ of a component A is defined as (a) Count of the number of components that can call, or pass control, to component A (b) Number of components related to component A (c) Number of components dependent on component A (d) None of the aboveSoftware En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


97

Multiple Choice Questions6.9 ‘FAN OUT’ of a component A is defined as (a) number of components related to component A (b) number of components dependent on component A (c) number of components that are called by component A (d) none of the above 6.10 Which is not a size metric? (a) LOC (b) Function count (c) Pro

ram len

th (d) Cyclomatic complexit

y 6.11 Which one is not a measure of software science theory? (a) Vocabulary (b) Volume (c) Level (d) Lo

ic 6.12 A human mind is capable of makin

how many numb

er of elementary mental discriminations per second (i.e., stroud number)? (a) 5 to 20 (b) 20 to 40 (c) 1 to 10 (d) 40 to 80Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


98

Multiple Choice Questions6.13 Minimal implementation of any al

orithm was

iven the followin

name by Hal

stead: (a) Volume (b) Potential volume (c) Effective volume (d) None of the above 6.14 Pro

ram volume of a software product is

(a) V=N lo 2n (c) V=2N lo

2n (b) V=(N/2) lo

2n (d) V=N lo

2n+1

6.15 Which one is the international standard for size measure? (a) LOC (b) Function count (c) Pro

ram len

th (d) None of the above 6.16 Which one is not an obje

ct oriented metric? (a) RFC (b) CBO (c)DAC (d) OBC

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


99

Multiple Choice Questions6.17 Which metric also consider indirect connected methods? (a) TCC (b) LCC (c) Both of the above (d) None of the above 6.18 depth of inheritance tree (DIT) can be measured by: (a) Number of ancestors classes (b) Number of successor classes (c) Number of failure classes (d) Number of root classes 6.19 A dynamic pa

e is

: (a) where contents are not dependent on the actions of the user (b) where contents are dependent on the actions of the user (c) where contents cannot be displayed (d) None of the above 6.20 Which of the followin

is not a size metric? (a)

LOC (b) FP (c) Cyclomatic Complexity (d) pro ram len

th

100

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Exercises6.1 Define software metrics. Why do we really need metrics in software? 6.2 Discus the areas of applications of software metrics? What are the problems durin

i

mplementation of metrics in any or anizations? 6.3 What are the various cate

ori

es of software metrics? Discuss with the help of suitable example. 6.4 Explain the Halstead theory of software science. Is it si

nificant in today’s scenario of c

omponent based software development? 6.5 What is the importance of lan ua e leve

l in Halstead theory of software science? 6.6 Give Halstead’s software science measure for: (i) Pro

ram Len

th (ii) Pro

ram volume (iii) Pro

ram level (iv) Effort

(v) Lan ua e level

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


101

Exercises6.7 For a pro

ram with number of unique operators η1 = 20 and num

�er of unique ope

rands η 2 = 40 , Compute te following: (i) Program volume (iii) Program lengt

(i

i) �ffort and time (iv) Program level

6.8 Develop a small software tool tat will perform a Halstead analysis on a pro

gramming language source code of your coice. 6.9 Write a program in C and also

PASCAL for te calculation of t

e roots of a quadratic equation, Find out all so

ftware science metrics for �ot te programs. Compare t

e outcomes and comment o

n te efficiency and size of

�ot te source codes. 6.10 How s

ould a procedure

identifier �e considered,

�ot wen declared and w

en called/ W

at a

�out t

e ide

ntifier of a procedure tat is passed as a parameter to anot

er procedure?


Sing

, Copyrig

t © New Ag


ers, 2007

102

�xercises6.11 Assume t

at t

e previous payroll program is expected to read a file contain

ing information a�out all t

e c

eques t

at

ave

�een printed. T

e file is suppos

ed to �e printed and also used

�y t

e program next time it is run, to produce a

report tat compares payroll expenses of t

e current mont

wit

tose of t

e pre

vious mont. Compute functions points for t

is program. Justify t

e difference

�etween t

e function points of t

is program and previous one

�y considering

ow t

e complexity of te program is affected

�y adding t

e requirement of interfacin

g wit anot

er application (in t

is case, itself). 6.12 Define data structure me

trics. How can we calculate amount of data in a program? 6.13 Descri�e t

e conce

pt of module weakness. Is it applica�le to programs also. 6.14 Write a program f

or te calculation of roots of a quadratic equation. Generate cross reference li

st for te program and also calculate for t

is program.


Sing

, Copyrig

t © New Ag


ers, 2007

103

�xercises6.15 S

ow t

at t

e value of SP at a particular statement is also t

e value of LV

at tat point. 6.16 Discuss t

e significance of data structure metrics during t

esting. 6.17 Wat are information flow metrics?

�xplain t

e �asic information fl

ow model. 6.18 Discuss te pro

�lems wit

metrics data.

�xplain two met

ods for t

e analysis of suc data. 6.19 S

ow w

y and

ow software metrics can improve t

e

software process. �numerate t

e effect of metrics on software productivity. 6.2

0 Wy does lines of code (LOC) not measure software nesting and control structur

es? 6.21 Several researcers in software metrics concentrate on data structure t

o measure complexity. Is data structure a complexity or quality issue, or �ot?


Sing

, Copyrig

t © New Ag


ers, 2007

104

�xercises6.22 List t

e �enefits and disadvantages of using Li

�rary routines rat

er t

an w

riting own code. 6.23 Compare software science measure and function points as measure of complexity. W

ic do you t

ink more useful as a predictor of

ow muc

p

articular software’s development will cost? 6.24 Some experimental evidence suggests t

at t

e initial size estimate for a project affects t

e nature and results o

f te project. Consider two different managers c

arged wit

developing t

e same

application. One estimates tat t

e size of t

e application will

�e 50,000 lines

, wile t

e ot

er estimates t

at it will

�e 100,000 lines. Discuss

ow t

ese est

imates affect te project t

roug

out its life cycle. 6.25 W

ic one is t

e most

appropriate size estimation tecnique and w

y? 6.26 Discuss t

e o

�ject oriented

metrics. Wat is t

e importance of metrics in o

�ject oriented software developme

nt ?


Sing

, Copyrig

t © New Ag


ers, 2007

105

�xercises6.27 Define t

e following: RFC, CBO, DAC, TCC, LCC & DIT. 6.28 W

at is t

e signi

ficance of use case metrics? Is it really important to design suc metrics?


Sing

, Copyrig

t © New Ag


ers, 2007

106


Sing

, Copyrig

t © New Ag


ers, 2007

1

Software Relia�ility

Basic ConceptsTere are t

ree p

ases in t

e life of any

ardware component i.e.,

�urn-in, usef

ul life & wear-out. In �urn-in p

ase, failure rate is quite

ig initially, and

it starts decreasing gradually as te time progresses. During useful life period

, failure rate is approximately constant. Failure rate increase in wear-out pas

e due to wearing out/aging of components. Te �est period is useful life period.

Te s

ape of t

is curve is like a “

�at tu

�” and t

at is w

y it is known as

�at tu�

curve. Te “

�at tu

� curve” is given in Fig.7.1.


Sing

, Copyrig

t © New Ag


ers, 2007

2


Fig. 7.1: Bat tu

� curve of

ardware relia

�ility.


Sing

, Copyrig

t © New Ag


ers, 2007

3


We do not ave wear out p

ase in software. T

e expected curve for software is gi

ven in fig. 7.2.

Fig. 7.2: Software relia�ility curve (failure rate versus time)


Sing

, Copyrig

t © New Ag


ers, 2007

4


Software may �e retired only if it

�ecomes o

�solete. Some of contri

�uting factor

s are given �elow:

cange in environment c

ange in infrastructure/tec

nology major c

ange in requir

ements increase in complexity extremely difficult to maintain deterioration in structure of t

e code slow execution speed poor grap

ical user interfaces


Sing

, Copyrig

t © New Ag


ers, 2007

5


Wat is Software Relia

�ility?

“Software relia�ility means operational relia

�ility. W

o cares

ow many

�ugs are i

n te program? As per I

�� standard: “Software relia

�ility is defined as t

e a

�ili

ty of a system or component to perform its required functions under stated conditions for a specified period of time”.


Sing

, Copyrig

t © New Ag


ers, 2007

6


Software relia�ility is also defined as t

e pro

�a�ility t

at a software system f

ulfills its assigned task in a given environment for a predefined num�er of inpu

t cases, assuming tat t

e ardware and t

e inputs are free of error. “It is t

e p

ro�a�ility of a failure free operation of a program for a specified time in a sp

ecified environment”.


Sing

, Copyrig

t © New Ag


ers, 2007

7


Failures and FaultsA fault is t

e defect in t

e program t

at, w

en executed under particular condit

ions, causes a failure. Te execution time for a program is t

e time t

at is act

ually spent �y a processor in executing t

e instructions of t

at program. T

e se

cond kind of time is calendar time. It is te familiar time t

at we normally exp

erience.


Sing

, Copyrig

t © New Ag


ers, 2007

8


Tere are four general ways of c

aracterising failure occurrences in time: 1. ti

me of failure, 2. time interval �etween failures, 3. cumulative failure experien

ced up to a given time, 4. failures experienced in a time interval.


Sing

, Copyrig

t © New Ag


ers, 2007

9


Failure Num�er 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Failure Time (sec) 8 18 25 36

45 57 71 86 104 124 143 169 197 222 250 Failure interval (sec) 8 10 7 11 9 12 14 15 18 20 19 26 28 25 28

Ta�le 7.1: Time

�ased failure specification


Sing

, Copyrig

t © New Ag


ers, 2007

10


Time (sec) 30 60 90 120 150 180 210 240 Cumulative Failures 3 6 8 9 11 12 13 14 Failure in interval (30 sec) 3 3 2 1 2 1 1 1

Ta�le 7.2: Failure

�ased failure specification


Sing

, Copyrig

t © New Ag


ers, 2007

11


Value of random varia�le (failures in time period) 0 1 2 3 4 5 6 7 8 9 Pro

�a�ili

ty �lapsed time tA = 1

r 0.10 0.18 0.22 0.16 0.11 0.08 0.05 0.04 0.03 0.02

�lap

sed time tB = 5 r 0.01 0.02 0.03 0.04 0.05 0.07 0.09 0.12 0.16 0.13

Ta�le 7.3: Pro

�a�ility distri

�ution at times tA and tB


Sing

, Copyrig

t © New Ag


ers, 2007

12


Value of random varia�le (failures in time period) 10 11 12 13 14 15 Mean failur

es Pro�a�ility

�lapsed time tA = 1

r 0.01 0 0 0 0 0 3.04

�lapsed time tB = 5

r

0.10 0.07 0.05 0.03 0.02 0.01 7.77

Ta�le 7.3: Pro

�a�ility distri

�ution at times tA and tB

13


Sing

, Copyrig

t © New Ag


ers, 2007


A random process wose pro

�a�ility distri

�ution varies wit

time to time is call

ed non-omogeneous. Most failure processes during test fit t

is situation. Fig.

7.3 illustrates te mean value and t

e related failure intensity functions at ti

me tA and tB. Note tat t

e mean failures experienced increases from 3.04 to 7.7

7 �etween t

ese two points, w

ile t

e failure intensity decreases. Failure

�eav

ior is affected �y two principal factors:

te num

�er of faults in t

e software

�eing executed. t

e execution environment o

r te operational profile of execution.

14


Sing

, Copyrig

t © New Ag


ers, 2007


Fig. 7.3: Mean Value & failure intensity functions.


Sing

, Copyrig

t © New Ag


ers, 2007

15

Software Relia�ility�

nvironmentTe environment is descri

�ed

�y t

e operational profile. T

e proportion of runs

of various types may vary, depending on te functional environment.

�xamples of

a run type migt �e:

1. a particular transaction in an airline reservation system or a �usiness data

processing system, 2. a specific cycle in a closed loop control system (for example, in a c

emical process industry), 3. a particular service performed

�y an op

erating system for a user.Software


Sing

, Copyrig

t © New Ag


ers, 2007

16


Te run types required of t

e program

�y t

e environment can

�e viewed as

�eing

selected randomly. Tus, we define t

e operational profile as t

e set of run typ

es tat t

e program can execute along wit

possi

�ilities wit

wic tey will oc

cur. In fig. 7.4, we sow two of many possi

�le input states A and B, wit

teir

pro�a�ilities of occurrence. T

e part of t

e operational profile for just t

ese

two states is sown in fig. 7.5. A realistic operational profile is illustrated

in fig.7.6.


Sing

, Copyrig

t © New Ag


ers, 2007

17


Fig. 7.4: Input Space


Sing

, Copyrig

t © New Ag


ers, 2007

18


Fig. 7.5: Portion of operational profileSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

19


Fig. 7.6: Operational profileSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

20


Fig.7.7 sows

ow failure intensity and relia

�ility typically vary during a test

period, as faults are removed.

Fig. 7.7: Relia�ility and failure intensity


Sing

, Copyrig

t © New Ag


ers, 2007

21


Uses of Relia�ility Studies

Tere are at least four ot

er ways in w

ic software relia

�ility measures can

�e

of great value to te software engineer, manager or user. 1. you can use softwa

re relia�ility measures to evaluate software engineering tec

nology quantitative

ly. 2. software relia�ility measures offer you t

e possi

�ility of evaluating dev

elopment status during te test p

ases of a project.


Sing

, Copyrig

t © New Ag


ers, 2007

22


3. one can use software relia�ility measures to monitor t

e operational performa

nce of software and to control new features added and design canges made to t

e

software. 4. a quantitative understanding of software quality and te various f

actors influencing it and affected �y it enric

es into t

e software product and

te software development process.


Sing

, Copyrig

t © New Ag


ers, 2007

23


Software QualityDifferent people understand different meanings of quality like:

conformance to requirements fitness for te purpose level of satisfaction


Sing

, Copyrig

t © New Ag


ers, 2007

24



Sing

, Copyrig

t © New Ag


ers, 2007

25


Fig 7.8: Software quality attri�utes


Sing

, Copyrig

t © New Ag


ers, 2007

26


1 2 3 4 5 6 7 Relia�ility Correctness Consistency & precision Ro

�ustness Simplic

ity Tracea�ility Usa

�ility T

e extent to w

ic a software performs its intended

functions witout failure. T

e extent to specifications. w

ic a software meets

its

Te extent to w

ic a software is consistent and give results wit

precision. T

e extent to w

ic a software tolerates t

e unexpected pro

�lems. T

e extent to w

ic a software is simple in its operations. T

e extent to w

ic an error is trac

ea�le in order to fix it. T

e extent of effort required to learn, operate and un

derstand te functions of t

e software


Sing

, Copyrig

t © New Ag


ers, 2007

27


8 9 Accuracy Clarity & Accuracy of documentation Conformity of operational environment Completeness

�fficiency Testa

�ility Maintaina

�ility Meeting specification

s wit precision. T

e extent to w

ic documents are clearly & accurately written

. Te extent to w

ic a software is in conformity of operational environment. T

e extent to w

ic a software

as specified functions. T

e amount of computing re

sources and code required �y software to perform a function. T

e effort required

to test a software to ensure tat it performs its intended functions. T

e effor

t required to locate and fix an error during maintenance pase.

10

11 12 13 14


Sing

, Copyrig

t © New Ag


ers, 2007

28


15 16 17 18 19 20 Modularity Reada�ility Adapta

�ility Modifia

�ility

�xpanda

�ilit

y Porta�ility It is t

e extent of ease to implement, test, de

�ug and maintain t

e software. T

e extent to w

ic a software is reada

�le in order to understand. T

e extent to wic a software is adapta

�le to new platforms & tec

nologies. T

e

effort required to modify a software during maintenance pase. T

e extent to w

i

c a software is expanda

�le wit

out undesira

�le side effects. T

e effort require

d to transfer a program from one platform to anoter platform.

Ta�le 7.4: Software quality attri

�utes


Sing

, Copyrig

t © New Ag


ers, 2007

29


McCall Software Quality Model

Fig 7.9: Software quality factorsSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

30


i. Product OperationFactors w

ic are related to t

e operation of a product are com

�ined. T

e factor

s are: Correctness �fficiency Integrity Relia

�ility Usa

�ility T

ese five factors

are related to operational performance, convenience, ease of usage and its correctness. T

ese factors play a very significant role in

�uilding customer’s satisfa

ction.Software


Sing

, Copyrig

t © New Ag


ers, 2007

31


ii. Product RevisionTe factors w

ic are required for testing & maintenance are com

�ined and are gi

ven �elow: Maintaina

�ility Flexi

�ility Testa

�ility T

ese factors pertain to t

e

testing & maintaina�ility of software. T

ey give us idea a

�out ease of maintenan

ce, flexi�ility and testing effort. Hence, t

ey are com

�ined under t

e um

�rella

of product revision.Software


Sing

, Copyrig

t © New Ag


ers, 2007

32


iii. Product TransitionWe may

ave to transfer a product from one platform to an ot

er platform or from

one tecnology to anot

er tec

nology. T

e factors related to suc

a transfer ar

e com�ined and given

�elow: Porta

�ility Reusa

�ility Interopera

�ility


Sing

, Copyrig

t © New Ag


ers, 2007

33


Most of te quality factors are explained in ta

�le 7.4. T

e remaining factors ar

e given in ta�le 7.5.

Sr.No. 1 2 3 4 Quality Factors Integrity Flexi�ility Reusa

�ility Interopera

�ilit

y Purpose Te extent to w

ic access to software or data

�y t

e unaut

orized per

sons can �e controlled. T

e effort required to modify an operational program. T

e extent to w

ic a program can

�e reused in ot

er applications. T

e effort requ

ired to couple one system wit anot

er.

Ta�le 7.5: Remaining quality factors (ot

er are in ta

�le 7.4)


Sing

, Copyrig

t © New Ag


ers, 2007

34

Quality criteria

Fig 7.10: McCall’s quality modelSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

35


Ta�le 7.5(a): Relation

�etween quality factors and quality criteria


Sing

, Copyrig

t © New Ag


ers, 2007

36


1 2 3 4 5 6 7 Opera�ility Training T

e ease of operation of t

e software. T

e ea

se wit wic new users can use t

e system.

Communicativeness Te ease wit

wic inputs and outputs can

�e assimilated. I/O

volume I/O rate Access control Access audit It is related to te I/O volume. It

is te indication of I/O rate. T

e provisions for control and protection of t

e

software and data. Te ease wit

wic software and data can

�e c

ecked for com

pliance wit standards or ot

er requirements. T

e run time storage requirements

of te software. T

e run-time efficiency of t

e software.

37

8 9

Storage efficiency �xecution efficiency


Sing

, Copyrig

t © New Ag


ers, 2007


10 11 12 13 14 15 16 17 Tracea�ility Completeness Accuracy

�rror tolerance Consi

stency Simplicity Conciseness Instrumentation Te a

�ility to requirements. link

software components to Te degree to w

ic a full implementation of t

e required

functionality as

�een ac

ieved. T

e precision of computations and output. T

e

degree to wic continuity of operation is ensured under adverse conditions. T

e

use of uniform design and implementation tecniques and notations t

roug

out a

project. Te ease wit

wic te software can

�e understood. T

e compactness of

te source code, in terms of lines of code. T

e degree to w

ic te software pro

vides for measurements of its use or identification of errors.


Sing

, Copyrig

t © New Ag


ers, 2007

38


18 19 20 21 22 23 24 25 �xpanda

�ility Genera

�ility Selfdescriptiveness Modularit

y Macine independence Software system independence Communication commonality T

e degree to w

ic storage requirements or software functions can

�e expanded. T

e �readt

of t

e potential application of software components. T

e degree to w

i

c te documents are self explanatory. T

e provision of

igly independent modul

es. Te degree to w

ic software is dependent on its associated

ardware. T

e de

gree to wic software is independent of its environment. T

e degree to w

ic st

andard protocols and interfaces are used.

Data commonality Te use of standard data representations. Ta

�le 7.5 (

�): Softwa

re quality criteriaSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

39


Boem Software Quality Model

Fig.7.11: Te Boe

m software quality model


Sing

, Copyrig

t © New Ag


ers, 2007

40


ISO 9126Functionality Relia

�ility Usa

�ility

�fficiency Maintaina

�ility Porta

�ility


Sing

, Copyrig

t © New Ag


ers, 2007

41


Caracteristic/ Attri

�ute Functionality • Suita

�ility • Accuracy • Interopera

�ility • Se

curity Relia�ility S

ort Description of t

e C

aracteristics and t

e concerns Add

ressed �y Attri

�utes C

aracteristics relating to ac

ievement of t

e �asic purpos

e for wic te software is

�eing engineered T

e presence and appropriateness of

a set of functions for specified tasks Te provision of rig

t or agreed results

or effects Software’s a�ility to interact wit

specified systems A

�ility to preve

nt unautorized access, w

eter accidental or deli

�erate, to program and data. C

aracteristics relating to capa�ility of software to maintain its level of perfo

rmance under stated conditions for a stated period of time Attri�utes of softwar

e tat

�ear on t

e frequency of failure

�y faults in t

e software


Sing

, Copyrig

t © New Ag


ers, 2007

• Maturity

42


• Fault tolerance • Recovera�ility A

�ility to maintain a specified level of performa

nce in cases of software faults or unexpected inputs Capa�ility and effort neede

d to reesta�lis

level of performance and recover affected data after possi

�le f

ailure. Caracteristics relating to t

e effort needed for use, and on t

e indivi

dual assessment of suc use,

�y a stated implied set of users.

Usa�ility

• Understanda�ility T

e effort required for a user to recognize t

e logical concep

t and its applica�ility. • Learna

�ility • Opera

�ility

�fficiency T

e effort required

for a user to learn its application, operation, input and output. Te ease of o

peration and control �y users. C

aracteristic related to t

e relations

ip

�etwee

n te level of performance of t

e software and t

e amount of resources used, und

er stated conditions.43


Sing

, Copyrig

t © New Ag


ers, 2007


• Time �eavior • Resource

�eavior Maintaina

�ility T

e speed of response and proces

sing times and troug

out rates in performing its function. T

e amount of resour

ces used and te duration of suc

use in performing its function. C

aracteristic

s related to te effort needed to make modifications, including corrections, imp

rovements or adaptation of software to canges in environment, requirements and

functions specifications. Te effort needed for diagnosis of deficiencies or cau

ses of failures, or for identification of parts to �e modified. T

e effort neede

d for modification, fault removal or for environmental cange. T

e risk of unexp

ected effect of modifications. Te effort needed for validating t

e modified sof

tware.

• Analyza�ility • C

angea

�ility • Sta

�ility • Testa

�ility


Sing

, Copyrig

t © New Ag


ers, 2007

44


Porta�ility C

aracteristics related to t

e a

�ility to transfer t

e software from

one organization or ardware or software environment to anot

er. T

e opportunit

y for its adaptation to different specified environments. Te effort needed to i

nstall te software in a specified environment. T

e extent to w

ic it ad

eres t

o standards or conventions relating to porta�ility. T

e opportunity and effort o

f using it in te place of ot

er software in a particular environment.

• Adapta�ility • Installa

�ility • Conformance • Replacea

�ility

Ta�le 7.6: Software quality c

aracteristics and attri

�utes – T

e ISO 9126 view


Sing

, Copyrig

t © New Ag


ers, 2007

45


Fig.7.12: ISO 9126 quality modelSoftware


Sing

, Copyrig

t © New Ag


ers, 2007

46


Software Relia�ility Models

Basic �xecution Time Model

� µ� λ ( µ ) = λ0 �1 − � � V � 0 � �

(1)

Fig.7.13: Failure intensity λ as a function of µ for basic mode�Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200747

Software Re�iabi�itydλ − λ0 = dµ V0(2)

Fig.7.14: Re�ationship betweenτ

& µ for basic model48


� © New Ag

e In�erna


Sof�ware Reliabili

�y

For a deriva�ion of

�his rela

�ionship, equa

�ion 1 can be wri

��en as:

� µ (τ ) � dµ (τ ) � = λ0 �1 − � dτ V0 � � �The above equa

�ion can be solved for

µ (τ ) and resul� in :

� � − λ0τ µ (τ ) = V0 �1 − exp� � V � � 0 �

��

(3)


�lishers, 2007

49


The failure intensity as a function of execution time is shown in figure given �

elow

� − λ0τ λ (τ ) = λ0 exp � � V � 0

� � � �

Fig.7.15: Fai�ure intensity versus execution time for basic mode�Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200750

Software Re�iabi�ityDerived quantities

Fig.7.16: Additiona� fai�ures required to be experienced to reach the Software Engineering (3 ed.), By K.K Aggarwa� & objective Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 2007rd

51

Software Re�iabi�ityFig.7.17: Additiona� time required to reach the objectiveThis can be derived in mathematica� form as:� λP ∆τ = Ln� λ0 � λF � V0

� � � �52


Software Re�iabi�ityExamp�e- 7.1Assume that a program wi�� experience 200 fai�ures in infinite time. It has now experienced 100. The initia� fai�ure intensity was 20 fai�ures/CPU hr. (i) Determine the current fai�ure intensity. (ii) Find the decrement of fai�ure intensity per fai�ure. (iii) Ca�cu�ate the fai�ures experienced and fai�ure intensity after 20 and 100 CPU hrs. of execution. (iv)Compute addition fai�ures and additiona� execution time required to reach the fai�ure intensity objective of 5 fai�ures/CPU hr. Use the basic execution time mode� for the above mentioned ca�cu�ations.Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200753

Software Re�iabi�itySo�ution Here Vo=200 fai�uresµ = 100 fai�uresλ0 = 20 fai�ures/CPU hr.(i) Current fai�ure intensity:� µ� λ ( µ ) = λ0 �1 − � � V � 0 � �

� 100 � = 20�1 − � = 20(1 − 0.5) = 10 failures/CPU hr � 200 �Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

54


(ii) Decrement of failure intensity per failure can �e calculated as:

dλ − λ0 20 = =− = −0.1 / CPU hr. dµ V0 200(iii) (a) Failures experienced & failure intensity after 20 CPU hr:

� � �1 − exp� − λ0τ µ (τ ) = V0 � � V � 0 �

��

� � − 20 × 20 � � = 200�1 − exp� � � = 200(1 − exp(1 − 2)) � � � 200 � � �= 200(1 − 0.1353) ≈ 173failuresSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

55


� − λ0τ � λ (τ ) = λ0 exp� � V � � � 0 � � − 20 × 20 � = 20 exp� � = 20 exp(−2) = 2.71 failu(�) Failures experienced & failure intensity after 100 CPU hr:

� � − λ0τ µ (τ ) = V0 �1 − exp� � V � � 0 �

��

� � − 20 × 100 � � = 200�1 − exp� � � = 200 failures(almost) � � � 200 � � �

� − λ0τ λ (τ ) = λ0 exp� � V � 0

� � � �56


Software Re�iabi�ity� − 20 × 100 � = 20 exp� � = 0.000908 failures / CPU hr � 200 �(iv) Additional failures (∆µ ) required to reach the fai�ure intensity objective of 5 fai�ures/CPU hr.� V0 � � 200 � � � ∆µ = � �(λP − λF ) = � �(10 − 5) = 50 failures � 20 � � λ0 �


Software Re�iabi�ityAdditiona� execution time required to reach fai�ure intensity objective of 5 fai�ures/CPU hr.� V0 � � λP ∆τ = � � Ln� �λ � �λ � 0� � F

� � � �

200 � 10 � = Ln� � = 6.93 CPU hr. 20 �5�


Software Re�iabi�ityLogarithmic Poisson Execution Time Mode� Fai�ure Intensityλ ( µ ) = λ0 exp(−θµ )

Fig.7.18: Relationship �etween


�lishers, 2007

59


dλ = −λ0θ exp(− µθ ) dµ dλ = −θλ dµ

Fig.7.19: Re�ationship betweenSoftware Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200760

Software Re�iabi�ityµ (τ ) =1

θ

Ln(λ0θτ + 1)

λ (τ ) = λ0 /(λ0θτ + 1)� λP ∆µ = Ln� θ � λF � 1 � � � �(4)

1� 1 1 � ∆τ = � − � θ � λF λP �

λ = Present fai�ure intensity λ = Fai�ure intensity objectiveP F


Software Re�iabi�ityExamp�e- 7.2Assume that the initia� fai�ure intensity is 20 fai�ures/CPU hr. The fai�ure intensity decay parameter is 0.02/fai�ures. We have experienced 100 fai�ures up to this time. (i) Determine the current fai�ure intensity. (ii) Ca�cu�ate the decrement of fai�ure intensity per fai�ure. (iii) Find the fai�ures experienced and fai�ure intensity after 20 and 100 CPU hrs. of execution. (iv)Compute the additiona� fai�ures and additiona� execution time required to reach the fai�ure intensity objective of 2 fai�ures/CPU hr. Use Logarithmic Poisson execution time mode� for the above mentioned ca�cu�ations.Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200762

Software Re�iabi�itySo�utionλ0 = 20 fai�ures/CPU hr. µ = 100 fai�uresθ = 0.02 / failures(i) Current failure intensity:

λ ( µ ) = λ0 exp(−θµ )= 20 exp (�0.02 x 100) = 2.7 failures/CPU hr.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

63


(ii) Decrement of failure intensity per failure can �e calculated as:

dλ = −θλ dµ= -.02 x 2.7 = -.054/CPU hr. (iii) (a) Fai�ures experienced & fai�ure intensity after 20 CPU hr:

µ (τ ) =

1

θ

Ln(λ0θτ + 1)

1 = Ln(20 × 0.02 × 20 + 1) = 109 failures 0.02Sof


� © New Ag

e In�erna


64


�y

λ (τ ) = λ0 / (λ0θτ + 1)= ( 20) /( 20 × .02 × 20 + 1) = 2.22 failures / CPU hr.(b) Failures experienced & failure in

�ensi

�y af

�er 100 CPU hr:

µ (τ ) =

1

θ

Ln(λ0θτ + 1)

1 = Ln(20 × 0.02 × 100 + 1) = 186 failures 0.02

λ (τ ) = λ0 / (λ0θτ + 1)= ( 20) /( 20 × .02 × 100 + 1) = 0.4878 failures / CPU hr.Sof


� © New Ag

e In�erna


65


�y

(iv) Addi�ional failures (∆µ ) required to reach the fai�ure intensity objective of

2 fai�ures/CPU hr.1 λP � 2.7 � ∆µ = Ln = Ln� � = 15 fai�ures θ λF 0.02 � 2 � 11� 1 1� 1 �1 1 � ∆τ = � − � = � 2 − 2.7 � = 6.5 CPU hr. θ � λF λP � 0.02 � �


Software Re�iabi�ityExamp�e- 7.3The fo��owing parameters for basic and �ogarithmic Poisson mode�s are given: (a) Determine the addition fai�ures and additiona� execution time required to reach the fai�ure intensity objective of 5 fai�ures/CPU hr. for both mode�s. (b) Repeat this for an objective function of 0.5 fai�ure/CPU hr. Assume that we start with the initia� fai�ure intensity on�y.Basic execution time mode� Logarithmic Poisson execution time mode�λ = 10 fai�ures/CPU hro

λ = 30 fai�ures/CPU hro

V = 100 fai�ureso

θ = 0.25 / failure67


�lishers, 2007


Solution (a) (i) Basic execution time model

∆µ =

V0

λ0

(λ P − λ F )

100 = (10 − 5) = 50 failures 10(Present failure intensity) in this case is same as failure intensity). Now,

λP

λ0

(initia�� λP ∆τ = Ln� λ0 � λF � V0

� � � �68


Software Re�iabi�ity100 � 10 � = Ln� � = 6.93 CPU hr. 10 �5�(ii) Logarithmic execution time mode�� λP ∆µ = Ln� θ � λF � 1 � � � �

1 � 30 � = Ln� � = 71.67 Fai�ures 0.025 � 5 �∆τ = 1� 1 1 � � � − �λ θ � F λP � �

=

1 �1 1 � Ln� − � = 6.66 CPU hr. 0.025 � 5 30 �69


�lishers, 2007


Logarithmic model has calculated more failures in almost some duration of execution time initially.

(�) Failure intensity o

�jective

(λF ) = 0.5 fai�ures/CPU hr.� λP ∆τ = Ln� λ0 � λF � V0 � � � �

(i) Basic execution time mode�∆µ =

V0

λ0

(λP − λF )

100 = (10 − 0.5) = 95 failures 10

100 � 10 � = Ln� � = 30 CPU /hr 10 � 0.05 �


�lishers, 2007

70


(ii) Logarithmic execution time model

1 � λP ∆µ = Ln� θ � λF �

� � � �

1 � 30 � = Ln� � = 164 fai�ures 0.025 � 0.5 �1� 1 1 � ∆τ = � �λ −λ � � θ� F P �1 � 1 1 � = − � = 78.66 CPU/hr � 0.025 � 0.5 30 �Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

71


Calendar Time ComponentThe calendar time component is

�ased on a de

�ugging process model. This model ta

kes into account: 1. resources used in operating the program for a given execution time and processing an associated

�uantity of failure. 2. resources

�uantitie

s availa�le, and 3. the degree to which a resource can

�e utilized (due to

�ottl

enecks) during the period in which it is limiting. Ta�le 7.7 will help in visual

izing these different aspects of the resources, and the parameters that result.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

72


Resource usageUsage parameters re

�uirements per Resource Failure identification personnel Fail

ure correction personnel Computer time CPU hr Failure µI Planned parameters Quantities availa

�le PI Utilisation 1

θI0

µf

Pf

Pf

θc

µc

Pc

Pc

Fig. : Calendar time component resources and parametersSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

73


Hence, to �e more precise, we have

X C = µ c ∆µ + θ c ∆τ

(for compu�er

�ime)

X f = µ f ∆µX I = µ I ∆µ + θ I ∆τdxT / dτ = θ r + µ r λ

(for fai�ure correction)(for fai�ure identification)Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200774

Software Re�iabi�ityCa�endar time to execution time re�ationshipdt / dτ = (1 / Pr pr )dxT / dτd� / dτ = (θ r + µ r λ ) / Pr pr


Software Re�iabi�ityFig.7.21: Ca�endar time to execution time ratio for different �imiting resourcesSoftware Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200777

Software Re�iabi�ityExamp�e- 7.4A team run test cases for 10 CPU hrs and identifies 25 fai�ures. The effort required per hour of execution time is 5 person hr. Each fai�ure requires 2 hr. on an average to verify and determine its nature. Ca�cu�ate the fai�ure identification effort required.


Software Re�iabi�itySo�ution As we know, resource usage is:X r = θ rτ + µ r µHere θ r = 15 person hr.

µ = 25 failures µ r = 2 hrs./failure

τ = 10 CPU hrs.Hence, Xr = 5 (10) + 2 (25)

= 50 + 50 = 100 person hr.


� © New Ag

e In�erna


79


�y

Example- 7.5Ini

�ial failure in

�ensi

�y (λ0 ) for a given software is 20 fai�ures/CPU hr. The fa

i�ure intensity objective (λF ) of 1 fai�ure/CPU hr. is to be achieved. Assume the fo��owing resource usage parameters.Resource Usage Fai�ure identification effort Fai�ure Correction effort Computer time

Per hour 2 Person hr. 0 1.5 CPU hr.

Per fai�ure 1 Person hr. 5 Person hr. 1 CPU hr.Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200780

Software Re�iabi�ity(a) What resources must be expended to achieve the re�iabi�ity improvement? Use the �ogarithmic Poisson execution time mode� with a fai�ure intensity decay parameter of 0.025/fai�ure. (b) If the fai�ure intensity objective is cut to ha�f, what is the effect on requirement of resources ?


Software Re�iabi�itySo�ution (a)� λP ∆µ = Ln� θ � λF � 1

� � � �

1 � 20 � = Ln� � = 119 fai�ures 0.025 � 1 �1� 1 1 � ∆τ = � �λ −λ � � θ� F P �

1 �1 1 � 1 (1 − 0.05) = 38 CPU hrs. = � − �= 0.025 � 1 20 � 0.025Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

82


Hence

X1 = µ1∆µ + θ1∆τ= 1 (119) + 2 (38) = 195 Person hrs.

X F = µF ∆µ= 5 (119) = 595 Person hrs.

X C = µc ∆µ + θc ∆τ= 1 (119) + (1.5) (38) = 176 CPU hr.


� © New Ag

e In�erna


83


�y

(b)

λF = 0.5 fai�ures/CPU hr.∆µ = 1 � 20 � Ln� � = 148 fai�ures 0.025 � 0.5 �1 � 1 1 � ∆τ = − � = 78 CPU hr. � 0.025 � 0.5 20 �So, XI = 1 (148) + 2 (78) = 304 Person hrs. XF = 5 (148) = 740 Person hrs. XC = 1 (148) + (1.5)(78) = 265 CPU hrs.


�lishers, 2007

84


Hence, if we cut failure intensity o�jective to half, resources re

�uirements are

not dou�led

�ut they are some what less. Note that

∆τ

is

approxima�ely doubled bu

� increases logari

�hmically. Thus,

�he resources increas

e will be be�ween a logari

�hmic increase and a linear increase for changes in fa

ilure in�ensi

�y objec

�ive.


� © New Ag

e In�erna


85


�y

Example- 7.6A program is expec

�ed

�o have 500 faul

�s. I

� is also assumed

�ha� one faul

� may

lead �o one failure only. The ini

�ial failure in

�ensi

�y was 2 failures/CPU hr. T

he program was �o be released wi

�h a failure in

�ensi

�y objec

�ive of 5 failures/1

00 CPU hr. Calcula�ed

�he number of failure experienced before release.


� © New Ag

e In�erna


86


�y

Solu�ion

The number of failure experienced during �es�ing can be calcula

�ed using

�he equ

a�ion men

�ioned below:

∆µ =Here

V0

λ0

(λP − λF )

V0 = 500 because one fau�t �eads to one fai�ureλ0 = 2 fai�ures/CPU hr. λF = 5 fai�ures/100 CPU hr.= 0.05 fai�ures/CPU hr.Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200787

Software Re�iabi�ity500 (2 − 0.05) ∆µ = 2= 487 fai�ures Hence 13 fau�ts are expected to remain at the re�ease instant of the software.

So


Software Re�iabi�ityThe Je�inski-Moranda Mode�λ (t ) = φ ( N − i + 1)where φ = Constant o� proportionality N = Total number o� errors present I = number o� errors �ound by time interval tiSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

89

Software Re�iabi�ityExamp�e- 7.7 There are 100 errors estimated to be present in a program. We have experienced 60 errors. Use Je�inski-Moranda mode� to ca�cu�ate fai�ure intensity with a given va�ue of φ=0.03. What will be �ailure intensity a�ter the experience o� 80 errors?So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

91

So�tware ReliabilitySolution N = 100 errors i = 60 �ailures φ = 0.03 We knowλ ( t ) = 0 . 03 (100 − 60 + 1 )= 0.03(100�60+1) = 1.23 failures/CPU hr.After 80 failures

λ (t ) = 0.03(100 − 80 + 1)= 0.63 failures/CPU hr.

Hence, there is continuous decrease in the failure intensity as the num�er of fa

ilure experienced increases.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

92


The Bug Seeding ModelThe

�ug seeding model is an outgrowth of a techni

�ue used to estimate the num

�er

of animals in a wild life population or fish in a pond.

Nt nt = N + N t n + nt n N = Nt nt n N = Ns nsSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

∧

93


Capa�ility Maturity Model

It is a strategy for improving the software process, irrespective of the actual life cycle model used.

Fig.7.23: Maturity levels of CMMSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

94


Maturity Levels:

Initial (Maturity Level 1) Repeata�le (Maturity Level 2) Defined (Maturity Level

3) Managed (Maturity Level 4) Optimizing (Maturity Level 5)Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

95


Maturity Level Initial Repeata�le Defined Managed Optimizing Characterization Ad

hoc Process Basic Project Management Process Definition Process Measurement Process Control

Fig.7.24: The five levels of CMMSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

96


Key Process AreasThe key process areas at level 2 focus on the software project’s concerns related to esta

�lishing

�asic project management controls, as summarized

�elow:


�lishers, 2007

97


The key process areas at level 3 address �oth project and organizational issues,

as summarized �elow:


�lishers, 2007

98



�lishers, 2007

99


The key process areas at level 4 focus on esta�lishing a

�uantitative understand

ing of �oth the software process and the software work products

�eing

�uilt, as

summarized �elow:


�lishers, 2007

100


The key process areas at level 5 cover the issues that �oth the organization and

the projects must address to implement continuous and measura�le software proce

ss improvement, as summarized �elow:


�lishers, 2007

101


Common Features


�lishers, 2007

102


ISO 9000The SEI capa

�ility maturity model initiative is an attempt to improve software

�uality

�y improving the process

�y which software is developed. ISO�9000 series

of standards is a set of document dealing with �uality systems that can

�e used

for �uality assurance purposes. ISO�9000 series is not just software standard. I

t is a series of five related standards that are applica�le to a wide variety of

industrial activities, including design/ development, production, installation, and servicing. Within the ISO 9000 Series, standard ISO 9001 for

�uality system

is the standard that is most applica�le to software development.


�lishers, 2007

103


Mapping ISO 9001 to the CMM

1. Management responsi�ility 2. Quality system 3. Contract review 4. Design cont

rol 5. Document control 6. Purchasing 7. Purchaser�supplied productSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

104


8. Product identification and tracea�ility 9. Process control 10. Inspection and

testing 11. Inspection, measuring and test e�uipment 12. Inspection and test st

atus 13. Control of nonconforming product 14. Corrective actionSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

105


15. Handling, storage, packaging and delivery 16. Quality records 17. Internal �

uality audits 18. Training 19. Servicing 20. Statistical techni�ues


�lishers, 2007

106


Contrasting ISO 9001 and the CMMThere is a strong correlation

�etween ISO 9001 and the CMM, although some issues

in ISO 9001 are not covered in the CMM, and some issues in the CMM are not addressed in ISO 9001. The

�iggest difference, however,

�etween these two documents

is the emphasis of the CMM on continuous process improvement. The �iggest simila

rity is that for �oth the CMM and ISO 9001, the

�ottom line is “Say what you do; d

o what you say”.


�lishers, 2007

107

Multiple Choice QuestionsNote: Choose most appropriate answer of the following

�uestions:

7.1 Which one is not a phase of “�ath tu

� curve” of hardware relia

�ility (a) Burn�in

(�) Useful life (c) Wear�out (d) Test�out 7.2 Software relia�ility is (a) the p

ro�a�ility of failure free operation of a program for a specified time in a spec

ified environment (�) the pro

�a�ility of failure of a program for a specified ti

me in a specified environment (c) the pro�a�ility of success of a program for a

specified time in any environment (d) None of the a�ove 7.3 Fault is (a) Defect

in the program (c) Error in the program 7.4 One fault may lead to (a) one failure (c) many failures (

�) Mistake in the program (d) All of the a

�ove (

�) two fail

ures (d) all of the a�ove

108


�lishers, 2007

Multiple Choice Questions7.5 Which ‘time’ unit is not used in relia

�ility studies (a) Execution time (

�) Mach

ine time (c) Clock time (d) Calendar time 7.6 Failure occurrences can �e represe

nted as (a) time to failure (�) time interval

�etween failures (c) failures expe

rienced in a time interval (d) All of the a�ove 7.7 Maximum possi

�le value of re

lia�ility is (a) 100 (

�) 10 (c) 1 (d) 0 7.8 Minimum possi

�le value of relia

�ilit

y is (a) 100 (�) 10 (c) 1 (d) 0 7.9 As the relia

�ility increases, failure intens

ity (a) decreases (�) increases (c) no effect (d) None of the a

�ove


�lishers, 2007

109

Multiple Choice Questions7.10 If failure intensity is 0.005 failures/hour during 10 hours of operation of a software, its relia

�ility can

�e expressed as (a) 0.10 (

�) 0.92 (c) 0.95 (d)

0.98 7.11 Software Quality is (a) Conformance to re�uirements (c) Level of satis

faction (�) Fitness for the purpose (d) All of the a

�ove

7.12 Defect rate is (a) num�er of defects per million lines of source code (

�) n

um�er of defects per function point (c) num

�er of defects per unit of size of so

ftware (d) All of the a�ove 7.13 How many product

�uality factors have

�een prop

osed in McCall �uality model? (a) 2 (

�) 3 (c) 11 (d) 6


�lishers, 2007

110

Multiple Choice Questions7.14 Which one is not a product

�uality factor of McCall

�uality model? (a) Prod

uct revision (�) Product operation (c) Product specification (d) Product transit

ion 7.15 The second level of �uality attri

�utes in McCall

�uality model are term

ed as (a) �uality criteria (

�) �uality factors (c)

�uality guidelines (d)

�ualit

y specifications 7.16 Which one is not a level in Boehm software �uality model ?

(a) Primary uses (�) Intermediate constructs (c) Primitive constructs (d) Final

constructs 7.17 Which one is not a software �uality model? (a) McCall model (

�)

Boehm model (c) ISO 9000 (d) ISO 9126 7.18 Basic execution time model was developed

�y (a) Bev.Littlewood (

�) J.D.Musa (c) R.Pressman (d) Victor Baisili


�lishers, 2007

111

Multiple Choice Questions7.19 NHPP stands for (a) Non Homogeneous Poisson Process (

�) Non Hetrogeneous Po

isson Process (c) Non Homogeneous Poisson Product (d) Non Hetrogeneous Poisson Product 7.20 In Basic execution time model, failure intensity is given

�y

� µ2 � (a ) λ ( µ ) = λ0 �1 − � V � � 0 � �� V � (c) λ ( µ ) = λ0 �1 − 0 � � µ� � �

� µ� (�) λ ( µ ) = λ0 �1 − � � V � 0 � �

� V � (d ) λ ( µ ) = λ0 �1 − 02 � � µ � � �

7.21 In Basic execution time model, additional num�er of failures re

�uired to ac

hieve a failure intensity o�jective (∆µ ) is expressed as

( a ) ∆µ = ( c ) ∆µ =

V0

λ0 λ0V0

(λP − λ F ) (λF − λP )

(b) ∆µ = ( d ) ∆µ =

V0

λ0 λ0V0

(λ F − λ P ) (λ P − λF )112


Mu�tip�e Choice Questions7.22 In Basic execution time mode�, additiona� time required to achieve a fai�ure intensity objective (∆τ ) is given as

( a ) ∆τ =

�λ Ln� F V0 � λP �

λ0

� � � � � � � �

(b) ∆τ =

�λ Ln� P V0 � λF �

λ0

� � � � � � � �

( c ) ∆τ =

V0

�λ Ln� F λ0 � λP �

(d ) ∆τ =

V0

�λ Ln� P λ0 � λF �

7.23 Fai�ure intensity function of Logarithmic Poisson execution mode� is given as

( a ) λ ( µ ) = λ0 LN (−θµ ) (c) λ ( µ ) = λ0 exp(−θµ )

(�) λ ( µ ) = λ0 exp(θµ ) ( d ) λ ( µ ) = λ0 �og(−θµ )

7.24 In Logarithmic Poisson execution model, ‘θ’ is known as (a) Failure intensity function parameter (

�) Failure intensity decay parameter (c) Failure intensity meas

urement (d) Failure intensity increment parameterSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

113

Multiple Choice Questions7.25 In jelinski�Moranda model, failure intensity is defined aseneous Poisson Product ( a ) λ (t ) = φ ( N − i + 1) (b) λ (t ) = φ ( N + i + 1)

(c) λ (t ) = φ ( N + i − 1)7.26 CMM level 1 has (a) 6 KPAs (c) 0 KPAs 7.27 MTB

� stands �or (a) Mean time be

tween �ailure (c) Minimum time between �ailures 7.28 CMM model is a technique to (a) Improve the so�tware process (c) Test the so�tware( d ) λ (t ) = φ ( N − i − 1)(b) 2 KPAs (d) None o� the above (b) Maximum time between �ailures (d) Many time between �ailures (b) Automatically develop the so�tware (d) All o� the above7.29 Total number o� maturing levels in CMM are (a) 1 (b) 3 (c) 5 (d) 7So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

114

Multiple Choice Questions7.30 Reliability o� a so�tware is dependent on number o� errors (a) removed (b) remaining (c) both (a) & (b) (d) None o� the above 7.31 Reliability o� so�tware is usually estimated at (a) Analysis phase (b) Design phase (c) Coding phase (d) Testing phase

7.32 CMM stands �or (a) Capacity maturity model (c) Cost management model(b) Capability maturity model (d) Comprehensive maintenance model

7.33 Which level o� CMM is �or basic project management? (a) Initial (b) Repeatable (c) De�ined (d) Managed 7.34 Which level o� CMM is �or process management? (a) Initial (b) Repeatable (c) De�ined (d) OptimizingSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

115

Multiple Choice Questions7.35 Which level o� CMM is �or process management? (a) Initial (b) De�ined (c) Managed (d) Optimizing 7.36 CMM was developed at (a) Harvard University (c) Carnegie Mellon University 7.37 McCall has developed a (a) Quality model(c) Requirement model

(b) Cambridge University (d) Maryland University(b) Process improvement model (d) Design model

7.38 The model to measure the so�tware process improvement is called (a) ISO 9000 (b) ISO 9126 (c) CMM (d) Spiral model 7.39 The number o� clauses used in ISO 9001 are (a) 15 (b) 25 (c) 20 (d) 10So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

116

Multiple Choice Questions7.40 ISO 9126 contains de�initions o� (a) quality characteristics(c) quality attributes (b) quality �actors (d) All o� the above7.41 In ISO 9126, each characteristics is related to (a) one attributes (b) two attributes (c) three attributes (d) �our attributes 7.42 In McCall quality model; product revision quality �actor consist o� (a) Maintainability (b) �lexibility (c) Testability (d) None o� the above 7.43 Which is not a so�tware reliability model ? (a) The Jelinski�Moranda Model (b) Basic execution time model (c) Spiral model (d) None o� the above 7.44 Each maturity model is CMM has (a) One KPA (c) Several KPAs (b) Equal KPAs (d) no KPA117


Multiple Choice Questions7.45 KPA in CMM stands �or (a) Key Process Area(c) Key Principal Area (b) Key Product Area (d) Key Per�ormance Area7.46 In reliability models, our emphasis is on (a) errors (b) �aults (c) �ailures (d) bugs 7.47 So�tware does not break or wear out like hardware. What is your opinion?(a) True (c) Can not say (b)

�alse (d) not �ixed

7.48 So�tware reliability is de�ined with respect to (a) time (b) speed (c) quality (d) None o� the above 7.49 MTT� stands �or (a) Mean time to �ailure (c) Minimum time to �ailure (b) Maximum time to �ailure (d) None o� the above118


Multiple Choice Questions7.50 ISO 9000 is a series o� standards �or quality management systems and has (a) 2 related standards (b) 5 related standards (c) 10 related standards (d) 25 related standards


119

Exercises7.1 What is so�tware reliability? Does it exist? 7.2 Explain the signi�icance o� bath tube curve o� reliability with the help o� a diagram. 7.3 Compare hardware reliability with so�tware reliability. 7.4 What is so�tware �ailure? How is it related with a �ault? 7.5 Discuss the various ways o� characterising �ailure occurrences with respect to time. 7.6 Describe the �ollowing terms: (i) Operational pro�ile (iii) MTB� (v) �ailure intensity. (ii) (iv) Input space MTT�So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007

120

Exercises7.7 What are uses o� reliability studies? How can one use so�tware reliability measures to monitor the operational per�ormance o� so�tware? 7.8 What is so�tware quality? Discuss so�tware quality attributes. 7.9 What do you mean by so�tware quality standards? Illustrate their essence as well as bene�its. 7.10 Describe the McCall so�tware quality model. How many product quality �actors are de�ined and why? 7.11 Discuss the relationship between quality �actors and quality criteria in McCall’s so�tware quality model. 7.12 Explain the Boehm so�tware quality model with the help o� a block diagram. 7.13 What is ISO9126 ? What are the quality characteristics and attributes?


121

Exercises7.14 Compare the ISO9126 with McCall so�tware quality model and highlight �ew advantages o� ISO9126. 7.15 Discuss the basic model o� so�tware reliability. How ∆µ and ∆τ can be calcula

�ed. 7.16 Assume

�ha� �he ini

�ial failure in

�ensi

�y is 6 failures

/CPU hr. The failure in�ensi

�y decay parame

�er is 0.02/failure. We assume

�ha� 4

5 failures have been experienced. Calcula�e �he curren

� failure in

�ensi

�y.

7.17 Explain �he basic & logari

�hmic Poisson model and

�heir significance in rel

iabili�y s

�udies.


� © New Ag

e In�erna


122

Exercises7.18 Assume

�ha� a program will experience 150 failures in infini

�e �ime. I

� has

now experienced 80. The ini�ial failure in

�ensi

�y was 10 failures/CPU hr. (i) D

e�ermine

�he curren

� failure in

�ensi

�y (ii) Calcula

�e �he failures experienced a

nd failure in�ensi

�y af

�er 25 and 40 CPU hrs. of execu

�ion. (iii) Compu

�e addi

�i

onal failures and addi�ional execu

�ion

�ime required

�o reach

�he failure in

�ens

i�y objec

�ive of 2 failures/CPU hr. Use

�he basic execu

�ion

�ime model for

�he a

bove men�ioned calcula

�ions. 7.19 Wri

�e a shor

� no

�e on Logari

�hmic Poisson Exec

u�ion

�ime model. How can we calcula

�e ∆µ & ∆τ ? 7.20 Assume

�ha� �he ini

�ial failure in�

ensi�y is 10 failures/CPU hr. The failure in

�ensi

�y decay parame

�er is 0.03/fai

lure. We have experienced 75 failures up�o �his

�ime. Find

�he failures experien

ced and failure in�ensi

�y af

�er 25 and 50 CPU hrs. of execu

�ion.


� © New Ag

e In�erna


123

Exercises7.21 The following parame

�ers for basic and logari

�hmic Poisson models are given

:

De�ermine

�he addi

�ional failures and addi

�ional execu

�ion

�ime required

�o reac

h �he failure in

�ensi

�y objec

�ive of 0.1 failure/CPU hr. for bo

�h models. 7.22 Q

uali�y and reliabili

�y are rela

�ed concep

�s bu

� are fundamen

�ally differen

� in a

number of ways. Discuss �hem. 7.23 Discuss

�he calendar

�ime componen

� model. E

s�ablish

�he rela

�ionship be

�ween calendar

�ime

�o execu

�ion

�ime.


� © New Ag

e In�erna


124

Exercises7.24 A program is expec

�ed

�o have 250 faul

�s. I

� is also assumed

�ha� one faul

� may lead

�o one failure. The ini

�ial failure in

�ensi

�y is 5 failure/CPU hr. The

program is released wi�h a failure in

�ensi

�y objec

�ive of 4 failures/10 CPU hr.

Calcula�e �he number of failures experienced before release. 7.25 Explain

�he J

elinski-Moranda model of reliabili�y �heory. Wha

� is

�he rela

�ion be

�ween ‘

�’ and

� λ

' ? 7.26 Describe the Mi��’s bu seedin model. Discuss few advanta es of this model over other reliability models. 7.27 Explain how the CMM encoura

es continuous

improvement of the software process. 7.28 Discuss various key process areas of CMM at various maturity levels. 7.29 Construct a table that correlates key process areas (KPAs) in the CMM with ISO9000. 7.30 Discuss the 20 clauses of ISO9001 and compare with the practices in the CMM.Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


125

Exercises7.31 List the difference of CMM and ISO9001. Why is it su

ested that CMM is the

better choice than ISO9001? 7.32 Explain the si nificance of software reliabili

ty en ineerin

. Discuss the advanta

e of usin

any software standard for softwar

e development? 7.33 What are the various key process areas at defined level in CMM? Describe activities associated with one key process area. 7.34 Discuss main requirements of ISO9001 and compare it with SEI capability maturity model. 7.35 Discuss the relative merits of ISO9001 certification and the SEI CMM based evaluation. Point out some of the shortcomin

s of the ISO9001 certification process a

s applied to the software industry.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


126

Software Testin

• What is Testin ?

Many people understand many definitions of testin : 1. Testin

is the process o

f demonstratin that errors are not present. 2. The purpose of testin

is to sho

w that a pro ram performs its intended functions correctly. 3. Testin

is the pr

ocess of establishin confidence that a pro

ram does what it is supposed to do.

These definitions are incorrect.2

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Software Testin

A more appropriate definition is:

“Testin is the process of executin

a pro

ram with the intent of findin

errors.”

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


3

Software Testin

• Why should We Test ?Althou

h software testin

is itself an expensive activity, yet launchin

of soft

ware without testin may lead to cost potentially much hi

her than that of testi

n , specially in systems where human safety is involved. In the software life cy

cle the earlier the errors are discovered and removed, the lower is the cost of their removal.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


4

Software Testin

• Who should Do the Testin ?

o Testin requires the developers to find errors from their software. o It is di

fficult for software developer to point out errors from own creations. o Many or anisations have made a distinction between development and testin

phase by mak

in different people responsible for each phase.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


5

Software Testin

• What should We Test ?We should test the pro

ram’s responses to every possible input. It means, we shoul

d test for all valid and invalid inputs. Suppose a pro ram requires two 8 bit in

te ers as inputs. Total possible combinations are 28x28. If only one second it r

equired to execute one set of inputs, it may take 18 hours to test all combinations. Practically, inputs are more than two and size is also more than 8 bits. We have also not considered invalid inputs where so many combinations are possible. Hence, complete testin

is just not possible, althou

h, we may wish to do so.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


6

Software Testin

Fi . 1: Control flow

raph

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


7

Software Testin

The number of paths in the example of Fi . 1 are 1014 or 100 trillions. It is co

mputed from 520 + 519 + 518 + …… + 51; where 5 is the number of paths throu h the lo

op body. If only 5 minutes are required to test one test path, it may take approximately one billion years to execute every path.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


8

Software Testin

Some Terminolo ies

Error, Mistake, Bu , Fault and Failure

People make errors. A ood synonym is mistake. This may be a syntax error or mis

understandin of specifications. Sometimes, there are lo

ical errors. When devel

opers make mistakes while codin , we call these mistakes “bu

s”. A fault is the repr

esentation of an error, where representation is the mode of expression, such as narrative text, data flow dia

rams, ER dia

rams, source code etc. Defect is a

o

od synonym for fault. A failure occurs when a fault executes. A particular fault may cause different failures, dependin

on how it has been exercised.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


9

Software Testin

Test, Test Case and Test SuiteTest and Test case terms are used interchan

eably. In practice, both are same an

d are treated as synonyms. Test case describes an input description and an expected output description.Test Case ID Section-I (Before Execution) Purpose : Pre condition: (If any) Inputs: Expected Outputs: Post conditions: Written by: Date: Section-II (After Execution) Execution History: Result: If fails, any possible reason (Optional); Any other observation: Any su

estion: Run by: Date:

Fi . 2: Test case template

The set of test cases is called a test suite. Hence any combination of test cases may

enerate a test suite.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


10

Software Testin

Verification and ValidationVerification is the process of evaluatin

a system or component to determine whe

ther the products of a iven development phase satisfy the conditions imposed at

the start of that phase. Validation is the process of evaluatin a system or co

mponent durin or at the end of development process to determine whether it sati

sfies the specified requirements . Testin = Verification+Validation

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


11

Software Testin

Alpha, Beta and Acceptance Testin

The term Acceptance Testin is used when the software is developed for a specifi

c customer. A series of tests are conducted to enable the customer to validate all requirements. These tests are conducted by the end user / customer and may ran e from adhoc tests to well planned systematic series of tests. The terms alpha

and beta testin are used when the software is developed as a product for anony

mous customers. Alpha Tests are conducted at the developer’s site by some potential customers. These tests are conducted in a controlled environment. Alpha testin may be started when formal testin

process is near completion. Beta Tests are

conducted by the customers / end users at their sites. Unlike alpha testin , dev

eloper is not present here. Beta testin is conducted in a real environment that

cannot be controlled by the developer.Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


12

Software Testin

Functional Testin

Input domain System under test Output domain

Input test data

Output test data

Fi . 3: Black box testin

Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


13

Software Testin

Boundary Value AnalysisConsider a pro

ram with two input variables x and y. These input variables have

specified boundaries as: a≤x≤bc≤y≤d

Input domain

d y c a x b14

Fi .4: Input domain for pro

ram havin

two input variables

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Software Testin

The boundary value analysis test cases for our pro ram with two inputs variables

(x and y) that may have any value from 100 to 300 are: (200,100), (200,101), (200,200), (200,299), (200,300), (100,200), (101,200), (299,200) and(300,200). This input domain is shown in Fi

. 8.5. Each dot represent a test cas

e and inner rectan le is the domain of le

itimate inputs. Thus, for a pro

ram of

n variables, boundary value analysis yield 4n + 1 test cases.

Input domain

400 300 y 200 100 0 100 200 x 300 400

Fi . 5: Input domain of two variables x and y with boundaries [100,300] each

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


15

Software Testin

Example- 8.I Consider a pro ram for the determination of the nature of roots of

a quadratic equation. Its input is a triple of positive inte ers (say a,b,c) and

values may be from interval [0,100]. The pro ram output may have one of the fol

lowin words. [Not a quadratic equation; Real roots; Ima

inary roots; Equal root

s] Desi n the boundary value test cases.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


16

Software Testin

Solution Quadratic equation will be of type: ax2+bx+c=0 Roots are real if (b2-4ac)>0 Roots are ima

inary if (b2-4ac)<0 Roots are equal if (b2-4ac)=0 Equation is

not quadratic if a=0

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


17

Software Testin

The boundary value test cases are :Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 a 0 1 50 99 100 50 50 50 50 50 50 50 50 b 50 50 50 50 50 0 1 99 100 50 50 50 50 c 50 50 50 50 50 50 50 50 50 0 1 99 100 Expected output Not Quadratic Real Roots Ima

inary Roots Ima

inary Roots Ima

ina

ry Roots Ima inary Roots Ima

inary Roots Ima

inary Roots Equal Roots Real Roots

Real Roots Ima inary Roots Ima

inary Roots

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


18

Software Testin

Example – 8.2 Consider a pro ram for determinin

the Previous date. Its input is a

triple of day, month and year with the values in the ran e 1 ≤ month ≤ 12 1 ≤ day ≤ 31

1900 ≤ year ≤ 2025 The possible outputs would be Previous date or invalid input date. Desi

n the boundary value test cases.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


19

Software Testin

Solution The Previous date pro ram takes a date as input and checks it for valid

ity. If valid, it returns the previous date as its output. With sin le fault ass

umption theory, 4n+1 test cases can be desi ned and which are equal to 13.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


20

Software Testin

The boundary value test cases are:Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 Month 6 6 6 6 6 6 6 6 6 1 2 11 12 Day 15 15 15 15 15 1 2 30 31 15 15 15 15 Year 1900 1901 1962 2024 2025 1962 1962 1962 1962 1962 1962 1962 1962 Expected output 14 June, 1900 14 June, 1901 14 June, 1962 14 June, 2024 14 June, 2025 31 May, 1962 1 June, 1962 29 June, 1962 Invalid date 14 January, 1962 14 February, 1962 14 November, 1962 14 December, 1962

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


21

Software Testin

Example – 8.3 Consider a simple pro ram to classify a trian

le. Its inputs is a tr

iple of positive inte ers (say x, y, z) and the date type for input parameters e

nsures that these will be inte ers

reater than 0 and less than or equal to 100.

The pro ram output may be one of the followin

words: [Scalene; Isosceles; Equi

lateral; Not a trian le] Desi

n the boundary value test cases.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


22

Software Testin

Solution The boundary value test cases are shown below:Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 x 50 50 50 50 50 50 50 50 50 1 2 99 100 y 50 50 50 50 50 1 2 99 100 50 50 50 50 z 1 2 50 99 100 50 50 50 50 50 50 50 50 Expected Output Isosceles Isosceles Equilateral Isosceles Not a trian

le Isoscel

es Isosceles Isosceles Not a trian le Isosceles Isosceles Isosceles Not a trian

le

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


23

Software Testin

Robustness testin

It is nothin but the extension of boundary value analysis. Here, we would like

to see, what happens when the extreme values are exceeded with a value sli htly

reater than the maximum, and a value sli htly less than minimum. It means, we w

ant to o outside the le

itimate boundary of input domain. This extended form of

boundary value analysis is called robustness testin and shown in Fi

. 6 There

are four additional test cases which are outside the le itimate input domain. He

nce total test cases in robustness testin are 6n+1, where n is the number of in

put variables. So, 13 test cases are: (200,99), (200,100), (200,101), (200,200), (200,299), (200,300) (200,301), (99,200), (100,200), (101,200), (299,200), (300,200), (301,200)Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


24

Software Testin

400 300 y 200 100 0 100 200 x 300 400

Fi . 8.6: Robustness test cases for two variables x and y with ran

e [100,300] e

achSoftware En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


25

Software Testin

Worst-case testin

If we reject “sin le fault” assumption theory of reliability and may like to see wha

t happens when more than one variable has an extreme value. In electronic circuits analysis, this is called “worst case analysis”. It is more thorou

h in the sense

that boundary value test cases are a proper subset of worst case test cases. It requires more effort. Worst case testin

for a function of n variables

enerate

5n test cases as opposed to 4n+1 test cases for boundary value analysis. Our two variables example will have 52=25 test cases and are

iven in table 1.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


26

Software Testin

Table 1: Worst cases test inputs for two variables exampleTest case number 1 2 3 4 5 6 7 8 9 10 11 12 13 Inputs x 100 100 100 100 100 101 101 101 101 101 200 200 200 y 100 101 200 299 300 100 101 200 299 300 100 101 200 Test case number 14 15 16 17 18 19 20 21 22 23 24 25 -Inputs x 200 200 299 299 299 299 299 300 300 300 300 300 y 299 300 100 101 200 299 300 100 101 200 299 300

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


27

Software Testin

Example - 8.4Consider the pro

ram for the determination of nature of roots of a quadratic equ

ation as explained in example 8.1. Desi n the Robust test case and worst test ca

ses for this pro ram.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


28

Software Testin

SolutionRobust test cases are 6n+1. Hence, in 3 variable input cases total number of test cases are 19 as

iven on next slide:

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


29

Software Testin

Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 a -1 0 1 50 99 100 101 50 50 50 50 50 50 50 50 50 50 50 50 b 50 50 50 50 50 50 50 -1 0 1 99 100 101 50 50 50 50 50 50 c 50 50 50 50 50 50 50 50 50 50 50 50 50 -1 0 1 99 100 101 Expected Output Invalid input� Not quadratic equation Real roots Ima inary roots Ima inary roots Ima

inary roots Invalid input Invalid input Ima

inary roots Ima

inar

y roots Ima inary roots Equal roots Invalid input Invalid input Real roots Real

roots Ima inary roots Ima

inary roots Invalid input

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


30

Software Testin

In case of worst test case total test cases are 5n. Hence, 125 test cases will be enerated in worst test cases. The worst test cases are

iven below:

Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 b 0 0 0 0 0 1 1 1 1 1 50 50 50 50 c 0 1 50 99 100 0 1 50 99 100 0 1 50 99 Expected output Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


31

Software Testin

Test Case 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 A 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 b 50 99 99 99 99 99 100 100 100 100 100 0 0 0 0 0 1 c 100 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 0 Expected output Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Not Quadratic Equal Roots Ima

inary Ima

inary

Ima inary Ima

inary Real Roots

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


32

Software Testin

Test Case 32 33 34 35 36 37 38 39 40 41 42 43 44� 45 46 47 48 A 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 b 1 1 1 1 50 50 50 50 50 99 99 99 99 99 100 100 100 C 1 50 99 100 0 1 50 99 100 0 1 50 99 100 0 1 50 Expected output Ima

inary Ima

inary Ima

i

nary Ima inary Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots

Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots Real Roots

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


33

Software Testin

Test Case 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 A 1 1 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 b 100 100 0 0 0 0 0 1 1 1 1 1 50 50 50 50 50 C 99 100 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 Expected output Real Roots Real Roots Equal Roots Ima

inary Ima

inary Ima

inary Ima

inary Real Roots Ima

inary I

ma inary Ima

inary Ima

inary Real Roots Real Roots Ima

inary Ima

inary Ima

inary

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


34

Software Testin

Test Case 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 A 50 50 50 50 50 50 50 50 50 50 99 99 99 99 99 99 99 b 99 99 99 99 99 100 100 100 100 100 0 0 0 0 0 1 1 C 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 0 1 Expected output Real Roots Real Roots Ima

inary Ima

inary Ima

inary Real Roots Real Roots Equal Roots Ima

i

nary Ima inary Equal Roots Ima

inary Ima

inary Ima

inary Ima

inary Real Roots Im

a inary

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


35

Software Testin

Test Case 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 A 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 b 1 1 1 50 50 50 50 50 99 99 99 99 99 100 100 100 100 100 C 50 99 100 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 Expected output Ima

inary Ima

inary Ima


inary Ima

inary

Ima inary Real Roots Real Roots Ima

inary Roots Ima

inary Ima

inary Real Roots

Real Roots Ima inary Ima

inary Ima

inary

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


36

Software Testin

Test Case 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 A 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 b 0 0 0 0 0 1 1 1 1 1 50 50 50 50 50 99 99 99 C 0 1 50 99 100 0 1 50 99 100 0 1 50 99 100 0 1 50 Expected output Equal Roots Ima

inary Ima

inary Ima

inary Ima

inary

Real Roots Ima inary Ima

inary Ima

inary Ima


in

ary Ima inary Ima


inary

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


37

Software Testin

Test Case 119 120 121 122 123 124 125 A 100 100 100 100 100 100 100 b 99 99 100 100 100 100 100 C 99 100 0 1 50 99 100 Expected output Ima

inary Ima

inary Real

Roots Real Roots Ima inary Ima

inary Ima

inary

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


38

Software Testin

Example – 8.5Consider the pro

ram for the determination of previous date in a calendar as exp

lained in example 8.2. Desi n the robust and worst test cases for this pro

ram.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


39

Software Testin

SolutionRobust test cases are 6n+1. Hence total 19 robust test cases are desi

ned and ar

e iven on next slide.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


40

Software Testin

Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Month 6 6 6 6 6 6 6 6 6 6 6 6 6 0 1 2 11 12 13 Day 15 15 15 15 15 15 15 0 1 2 30 31 32 15 15 15 15 15 15 Year 1899 1900 1901 1962 2024 2025 2026 1962 1962 1962 1962 1962 1962 1962 1962 1962 1962 1962 1962 Expected Output Invalid date (outside ran

e) 14 June, 190

0 14 June, 1901 14 June, 1962 14 June, 2024 14 June, 2025 Invalid date (outside ran

e) Invalid date 31 May, 1962 1 June, 1962 29 June, 1962 Invalid date Invalid

date Invalid date 14 January, 1962 14 February, 1962 14 November, 1962 14 December, 1962 Invalid date

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


41

Software Testin

In case of worst test case total test cases are 5n. Hence, 125 test cases will be enerated in worst test cases. The worst test cases are

iven below:

Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Month 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Day 1 1 1 1 1 2 2 2 2 2 15 15 15 15 Year 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 Expected output 31 December, 1899 31 December, 1900 31 December, 1961 31 December, 2023 31 December, 2024 1 January, 1900 1 January, 1901 1 January, 1962 1 January, 2024 1 January, 2025 14 January, 1900 14 January, 1901 14 January, 1962 14 January, 2024

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


42

Software Testin

Test Case 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 A 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 b 15 30 30 30 30 30 31 31 31 31 31 1 1 1 1 1 2 c 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 Expected output 14 January, 2025 29 January, 1900 29 January, 1901 29 January, 1962 29 January, 2024 29 January, 2025 30 January, 1900 30 January, 1901 30 January, 1962 30 January, 2024 30 January, 2025 31 January, 1900 31 January, 1901 31 January, 1962 31 January, 2024 31 January, 2025 1 February, 1900

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


43

Software Testin

Test Case 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 Month 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Day 2 2 2 2 15 15 15 15 15 30 30 30 30 30 31 31 31 Year 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 Expected output 1 February, 1901 1 February, 1962 1 February, 2024 1 February, 2025 14 February, 1900 14 February, 1901 14 February, 1962 14 February, 2024 14 February, 2025 Invalid date Invalid date Invalid date Invalid date Invalid date Invalid date Invalid date Invalid date

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


44

Software Testin

Test Case 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Month 2 2 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 Day 31 31 1 1 1 1 1 2 2 2 2 2 15 15 15 15 15 Year 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 Expected output Invalid date Invalid date 31 May, 1900 31 May, 1901 31 May, 1962 31 May, 2024 31 May, 2025 1 June, 1900 1 June, 1901 1 June, 1962 1 June, 2024 1 June, 2025 14 June, 1900 14 June, 1901 14 June, 1962 14 June, 2024 14 June, 2025

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


45

Software Testin

Test Case 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 Month 6 6 6 6 6 6 6 6 6 6 11 11 11 11 11 11 11 Day 30 30 30 30 30 31 31 31 31 31 1 1 1 1 1 2 2 Year 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 Expected output 29 June, 1900 29 June, 1901 29 June, 1962 29 June, 2024 29 June, 2025 Invalid date Invalid date Invalid date Invalid date Invalid date 31 October, 1900 31 October, 1901 31 October, 1962 31 October, 2024 31 October, 2025 1 November, 1900 1 November, 1901

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


46

Software Testin

Test Case 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 Month 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 Day 2 2 2 15 15 15 15 15 30 30 30 30 30 31 31 31 31 31 Year 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 Expected output 1 November, 1962 1 November, 2024 1 November, 2025 14 November, 1900 14 November, 1901 14 November, 1962 14 November, 2024 14 November, 2025 29 November, 1900 29 November, 1901 29 November, 1962 29 November, 2024 29 November, 2025 Invalid date Invalid date Invalid date Invalid date Invalid date

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


47

Software Testin

Test Case 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 Month 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 Day 1 1 1 1 1 2 2 2 2 2 15 15 15 15 15 30 30 30 Year 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 2024 2025 1900 1901 1962 Expected output 30 November, 1900 30 November, 1901 30 November, 1962 30 November, 2024 30 November, 2025 1 December, 1900 1 December, 1901 1 December, 1962 1 December, 2024 1 December, 2025 14 December, 1900 14 December, 1901 14 December, 1962 14 December, 2024 14 December, 2025 29 December, 1900 29 December, 1901 29 December, 1962

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


48

Software Testin

Test Case 119 120 121 122 123 124 125 Month 12 12 12 12 12 12 12 Day 30 30 31 31 31 31 31 Year 2024 2025 1900 1901 1962 2024 2025 Expected output 29 December, 2024 29 December, 2025 30 December, 1900 30 December, 1901 30 December, 1962 30 December, 2024 30 December, 2025

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


49

Software Testin

Example – 8.6Consider the trian

le problem as

iven in example 8.3. Generate robust and worst

test cases for this problem.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


50

Software Testin

SolutionRobust test cases are

iven on next slide.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


51

Software Testin � 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 x 50 50 50 50 50 50 50 50 50 5

0 50 50 50 0 1 2 99 100 100 y 50 50 50 50 50 50 50 0 1 2 99 100 101 50 50 50 50 50 50 z 0 1 2 50 99 100 101 50 50 50 50 50 50 50 50 50 50 50 50 Expected Output Invalid input� Isosceles Isosceles Equilateral Isosceles Not a trian le Invalid input Invalid input Isosceles Isosceles Isosceles Not a trian

le Invalid input I

nvalid input Isosceles Isosceles Isosceles Not a trian le Invalid input

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


52

Software Testin

Worst test cases are 125 and are iven below:

Test Case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 x 1 1 1 1 1 1 1 1 1 1 1 1 1 1 y 1 1 1 1 1 2 2 2 2 2 50 50 50 50 z 1 2 50 99 100 1 2 50 99 100 1 2 50 99 Expected output Equilateral Not a trian

le Not a trian

le Not a trian

le Not a trian

le Not a

trian le Isosceles Not a trian

le Not a trian

le Not a trian

le Not a trian

le

Not a trian le Isosceles Not a trian

le

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


53

Software Testin

Test Case 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 A 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 b 50 99 99 99 99 99 100 100 100 100 100 1 1 1 1 1 2 c 100 1 2 50 99 100 1 2 50 99 100 1 2 50 99 100 1 Expected output Not a trian

le Not a tria

n le Not a trian

le Not a trian

le Isosceles Not a trian

le Not a trian

le Not a

trian le Not a trian

le Not a trian


le Isosceles Not a

trian le Not a trian

le Not a trian

le Isosceles

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


54

Software Testin

Test Case 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 A 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 b 2 2 2 2 50 50 50 50 50 99 99 99 99 99 100 100 100 C 2 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 50 Expected output Equilateral Not a trian

le

Not a trian le Not a trian

le Not a trian

le Not a trian

le Isosceles Not a tri

an le Not a trian

le Not a trian

le Not a trian

le Not a trian

le Isosceles Scal

ene Not a trian le Not a trian

le Not a trian

le

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


55

Software Testin

Test Case 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 A 2 2 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 b 100 100 1 1 1 1 1 2 2 2 2 2 50 50 50 50 50 C 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 50 99 Expected output Scalene Isosceles Not a trian

le Not a trian


le Not a trian

le Not a tri

an le Not a trian


le Not a trian

le Isosceles Isosceles

Equilateral Isosceles Not a trian le

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


56

Software Testin

Test Case 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 A 50 50 50 50 50 50 50 50 50 50 50 99 99 99 99 99 99 B 99 99 99 99 99 100 100 100 100 100 1 1 1 1 1 2 2 C 1 2 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 Expected output Not a trian le Not a trian

le Isosceles Isosceles Scalene Not a trian

le Not a trian

le Not

a trian le Scalene Isosceles Not a trian

le Not a trian

le Not a trian

le Isosc

eles Not a trian le Not a trian

le Not a trian

le

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


57

Software Testin

Test Case 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 A 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 b 2 2 2 50 50 50 50 50 99 99 99 99 99 100 100 100 100 100 C 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 50 99 100 Expected output Not a trian

le Isosceles Scalene Not a trian

le Not a trian

le Isoscele

s Isosceles Scalene Isosceles Isosceles Isosceles Equilateral Isosceles Not a trian

le Scalene Scalene Isosceles Isosceles

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


58

Software Testin

Test Case 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 A 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 b 1 1 1 1 1 2 2 2 2 2 50 50 50 50 50 99 99 99 C 1 2 50 99 100 1 2 50 99 100 1 2 50 99 100 1 2 50 Expected output Not a trian

le Not a trian

le Not a trian

le Not a

trian le Isosceles Not a trian

le Not a trian

le Not a trian

le Scalene Isoscele

s Not a trian le Not a trian

le Not a trian

le Scalene Isosceles Not a trian

le

Scalene Scalene

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


59

Software Testin

Test Case 119 120 121 122 123 124 125 A 100 100 100 100 100 100 100 b 99 99 100 100 100 100 100 C 99 100 1 2 50 99 100 Expected output Isosceles Isosceles Isosceles Isosceles Isosceles Isosceles Equilateral

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


60

Software Testin

Equivalence Class Testin

In this method, input domain of a pro ram is partitioned into a finite number of

equivalence classes such that one can reasonably assume, but not be absolutely sure, that the test of a representative value of each class is equivalent to a test of any other value. Two steps are required to implementin

this method: 1. T

he equivalence classes are identified by takin each input condition and partiti

onin it into valid and invalid classes. For example, if an input condition spec

ifies a ran e of values from 1 to 999, we identify one valid equivalence class [

1<item<999]; and two invalid equivalence classes [item<1] and [item>999]. 2. Generate the test cases usin

the equivalence classes identified in the previous st

ep. This is performed by writin test cases coverin

all the valid equivalence c

lasses. Then a test case is written for each invalid equivalence class so that no test contains more than one invalid class. This is to ensure that no two invalid classes mask each other.Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


61

Software Testin

Invalid input Valid inputs System under test Outputs

Input domain

Output domain

Fi . 7: Equivalence partitionin

Most of the time, equivalence class testin

defines classes of the input domain.

However, equivalence classes should also be defined for output domain. Hence, we should desi

n equivalence classes based on input and output domain.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


62

Software Testin

Example 8.7Consider the pro

ram for the determination of nature of roots of a quadratic equ

ation as explained in example 8.1. Identify the equivalence class test cases for output and input domains.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


63

Software Testin

Solution Output domain equivalence class test cases can be identified as follows: O1={<a,b,c>:Not a quadratic equation if a = 0} O1={<a,b,c>:Real roots if (b2-4ac)>0} O1={<a,b,c>:Ima

inary roots if (b2-4ac)<0} O1={<a,b,c>:Equal roots if (b2

-4ac)=0}� The number of test cases can be derived form above relations and shown below:Test case 1 2 3 4 a 0 1 50 50 b 50 50 50 100 c 50 50 50 50 Expected output Not a quadratic equation Real roots Ima

inary roots Equal roots

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


64

Software Testin

We may have another set of test cases based on input domain. I1= {a: a = 0} I2= {a: a < 0} I3= {a: 1 ≤ a ≤ 100} I4= {a: a > 100} I5= {b: 0 ≤ b ≤ 100} I6= {b: b < 0} I7= {b: b > 100} I8= {c: 0 ≤ c ≤ 100} I9= {c: c < 0} I10={c: c > 100}

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


65

Software Testin

Test Case 1 2 3 4 5 6 7 8 9 10 a 0 -1 50 101 50 50 50 50 50 50 b 50 50 50 50 50 -1 101 50 50 50 c 50 50 50 50 50 50 50 50 -1 101 Expected output Not a quadratic equation Invalid input Ima

inary Roots invalid input Ima

inary Roots invalid in

put invalid input Ima inary Roots invalid input invalid input

Here test cases 5 and 8 are redundant test cases. If we choose any value other than nominal, we may not have redundant test cases. Hence total test cases are 10+4=14 for this problem.Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


66

Software Testin

Example 8.8Consider the pro

ram for determinin

the previous date in a calendar as explaine

d in example 8.3. Identify the equivalence class test cases for output & input domains.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


67

Software Testin

SolutionOutput domain equivalence class are: O1={<D,M,Y>: Previous date if all are valid inputs} O1={<D,M,Y>: Invalid date if any input makes the date invalid}

Test case 1 2

M 6 6

D 15 31

Y 1962 1962

Expected output 14 June, 1962 Invalid date

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


68

Software Testin

We may have another set of test cases which are based on input domain. I1={month: 1 ≤ m ≤ 12} I2={month: m < 1} I3={month: m > 12} I4={day: 1 ≤ D ≤ 31} I5={day: D < 1} I6={day: D > 31} I7={year: 1900 ≤ Y ≤ 2025} I8={year: Y < 1900} I9={year: Y > 2025}

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


69

Software Testin

Inputs domain test cases are :Test Case 1 2 3 4 5 6 7 8 9 M 6 -1 13 6 6 6 6 6 6 D 15 15 15 15 -1 32 15 15 15 Y 1962 1962 1962 1962 1962 1962 1962 1899 2026 Expected output 14 June, 1962 Invalid input invalid input 14 June, 1962 invalid input invalid input 14 June, 1962 invalid input (Value out of ran

e) invalid input (Value out of ran

e)

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


70

Software Testin

Example – 8.9Consider the trian

le problem specified in a example 8.3. Identify the equivalen

ce class test cases for output and input domain.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


71

Software Testin

SolutionOutput domain equivalence classes are: O1={<x,y,z>: Equilateral trian

le with si

des x,y,z} O1={<x,y,z>: Isosceles trian le with sides x,y,z} O1={<x,y,z>: Scalen

e trian le with sides x,y,z} O1={<x,y,z>: Not a trian

le with sides x,y,z} The t

est cases are:Test case 1 2 3 4 x 50 50 100 50 y 50 50 99 100 z 50 99 50 50 Expected Output Equilateral Isosceles Scalene Not a trian

le

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


72

Software Testin

Input domain based classes are: I1={x: x < 1} I2={x: x > 100} I3={x: 1 ≤ x ≤ 100} I4={y: y < 1} I5={y: y > 100} I6={y: 1 ≤ y ≤ 100} I7={z: z < 1} I8={z: z > 100} I9={z: 1 ≤ z ≤ 100}

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


73

Software Testin

Some inputs domain test cases can be obtained usin the relationship amon

st x,y

and z. I10={< x,y,z >: x = y = z} I11={< x,y,z >: x = y, x ≠ z} I12={< x,y,z >: x = z, x ≠ y} I13={< x,y,z >: y = z, x ≠ y} I14={< x,y,z >: x ≠ y, x ≠ z, y ≠ z} I15={< x,y,z >: x = y + z} I16={< x,y,z >: x > y +z} I17={< x,y,z >: y = x +z} I18={< x,y,z >: y > x + z} I19={< x,y,z >: z = x + y} I20={< x,y,z >: z > x +y}Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


74

Software Testin

Test cases derived from input domain are:Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 x 0 101 50 50 50 50 50 50 50 60 50 50 60 y 50 50 50 0 101 50 50 50 50 60 50 60 50 z 50 50 50 50 50 50 0 101 50 60 60 50 50 Expected Output Invalid input Invalid input Equilateral Invalid input Invalid input Equilateral Invalid input Invalid input Equilateral Equilateral Isosceles Isosceles Isosceles

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


75

Software Testin

Test case 14 15 16 17 18 19 20

x 100 100 100 50 50 50 25

y 99 50 50 100 100 50 50

z 50 50 25 50 25 100 100

Expected Output Scalene Not a trian le Not a trian

le Not a trian

le Not a trian

le Not a trian le Not a trian

le

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


76

Software Testin

Decision Table Based Testin

Condition Stub True C1 True C2 C3 Action Stub a1 a2 a3 a4 True X X X X False X X X X X True False True X X False --False True False Entry False

Table 2: Decision table terminolo y

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


77

Software Testin

Test case desi n

C1:x,y,z are sides of a trian le? C2:x = y? C3:x = z? C4:y = z? a1: Not a trian

le a2: Scalene a3: Isosceles a4: Equilateral a5: Impossible

N ---X Y Y N Y Y N N

Y N Y Y N Y N N

X X X X X X78

X

X

Table 3: Decision table for trian le problem

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Software Testin

Conditions C1 : x < y + z ? C2 : y < x + z ? C3 : z < x + y ? C4 : x = y ? C5 : x = z ? C6 : y = z ? a1 : Not a trian

le a2 : Scalene a3 : Isosceles a4 : Equila

teral a5 : Impossible X X X X X X X F -----X T F ----X T T F ---X X T T T T T T T T T T T F T T T T F T T T T T F F T T T F T T T T T F T F T T T F F T T T T F F F

Table 4: Modified decision tableSoftware En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


79

Software Testin

Example 8.10 Consider the trian le pro

ram specified in example 8.3. Identify th

e test cases usin the decision table of Table 4.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


80

Software Testin

SolutionThere are eleven functional test cases, three to fail trian

le property, three i

mpossible cases, one each to et equilateral, scalene trian

le cases, and three

to et on isosceles trian

le. The test cases are

iven in Table 5.

Test case 1 2 3 4 5 6 7 8 9 10 11 x 4 1 1 5 ? ? 2 ? 2 3 3 y 1 4 2 5 ? ? 2 ? 3 2 4 z 2 2 4 5 ? ? 3 ? 2 2 5 Expected Output Not a trian

le Not a trian

le Not a tr

ian le Equilateral Impossible Impossible Isosceles Impossible Isosceles Isoscele

s Scalene

Test cases of trian le problem usin

decision table

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


81

Software Testin

Example 8.11 Consider a pro ram for the determination of Previous date. Its inpu

t is a triple of day, month and year with the values in the ran e 1 ≤ month ≤ 12 1 ≤ d

ay ≤ 31 1900 ≤ year ≤ 2025 The possible outputs are “Previous date” and “Invalid date”. Desi the test cases usin

decision table based testin

.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


82

Software Testin

SolutionThe input domain can be divided into followin

classes: I1= {M1: month has 30 da

ys} I2= {M2: month has 31 days except March, Au ust and January} I3= {M3: month

is March} I4= {M4: month is Au ust} I5= {M5: month is January} I6= {M6: month is

February} I7= {D1: day = 1} I8= {D2: 2 ≤ day ≤ 28} I9= {D3: day = 29} I10={D4: day = 30} I11={D5: day = 31} I12={Y1: year is a leap year} I13={Y2: year is a common year}Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


83

Software Testin

The decision table is iven below:

Sr.No. C1: Months in C2: days in C3: year in a1: Impossible a2: Decrement day a3: Reset day to 31 a4: Reset day to 30 a5: Reset day to 29 a6: Reset day to 28 a7: decrement month a8: Reset month to December a9: Decrement yearSoftware En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


1M1 D1 Y1

2M1 D1 Y2

3M1 D2 Y1

4M1 D2 Y2

5M1 D3 Y1

6M1 D3 Y2

7M1 D4 Y1

8M1 D4 Y2

9M1 D5 Y1 X

10M1 D5 Y2 X

11M2 D1 Y1

12M2 D1 Y2

13M2 D2 Y1

14M2 D2 Y2

15M2 D3 Y1

X X X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

84

Software Testin


ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


16M2 D3 Y2

17M2 D4 Y1

18M2 D4 Y2

19M2 D5 Y1

20M2 D5 Y2

21M3 D1 Y1

22M3 D1 Y2

23M3 D2 Y1

24M3 D2 Y2

25M3 D3 Y1

26M3 D3 Y2

27M3 D4 Y1

28M3 D4 Y2

29M3 D5 Y1

30M3 D5 Y2

X

X

X

X

X

X

X

X

X

X

X

X

X

X X X X

85

Software Testin


ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


31M4 D1 Y1

32M4 D1 Y2

33M4 D2 Y1

34M4 D2 Y2

35M4 D3 Y1

36M4 D3 Y2

37M4 D4 Y1

38M4 D4 Y2

39M4 D5 Y1

40M4 D5 Y2

41M5 D1 Y1

42M5 D1 Y2

43M5 D2 Y1

44M5 D2 Y2

45M5 D3 Y1

X X X

X

X

X

X

X

X

X X X

X

X

X

X

X X X X X

86

Software Testin


ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


46M5 D3 Y2

47M5 D4 Y1

48M5 D4 Y2

49M5 D5 Y1

50M5 D5 Y2

51M6 D1 Y1

52M6 D1 Y2

53M6 D2 Y1

54M6 D2 Y2

55M6 D3 Y1

56M6 D3 Y2 X

57M6 D4 Y1 X

58M6 D4 Y2 X

59M6 D5 Y1 X

60M6 D5 Y2 X

X

X

X

X

X X X

X

X

X

X

X

87

Software Testin

Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Month June June June June June June June June June June May May May May May Day 1 1 15 15 29 29 30 30 31 31 1 1 15 15 29 Year 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 Expected output 31 May, 1964 31 May, 1962 14 June, 1964 14 June, 1962 28 June, 1964 28 June, 1962 29 June, 1964 29 June, 1962 Impossible Impossible 30 April, 1964 30 April, 1962 14 May, 1964 14 May, 1962 28 May, 196488

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Software Testin

Test case 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Month May May May May May March March March March March March March March March March Day 29 30 30 31 31 1 1 15 15 29 29 30 30 31 31 Year 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 Expected output 28 May, 1962 29 May, 1964 29 May, 1962 30 May, 1964 30 May, 1962 29 February, 1964 28 February, 1962 14 March, 1964 14 March, 1962 28 March, 1964 28 March, 1962 29 March, 1964 29 March, 1962 30 March, 1964 30 March, 196289

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Software Testin

Test case 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 Month Au ust Au

ust Au

us

t Au ust Au

ust Au

ust Au

ust Au

ust Au

ust Au

ust January January January Janua

ry January Day 1 1 15 15 29 29 30 30 31 31 1 1 15 15 29 Year 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 Expected output 31 July, 1962 31 July, 1964 14 Au

ust, 1964 14 Au

ust, 1962 28 Au

ust, 1964 28 Au

ust, 1

962 29 Au ust, 1964 29 Au

ust, 1962 30 Au

ust, 1964 30 Au

ust, 1962 31 December,

1964 31 December, 1962 14 January, 1964 14 January, 1962 28 January, 196490

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Software Testin

Test case 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 Month January January January January January February February February February February February February February February February Day 29 30 30 31 31 1 1 15 15 29 29 30 30 31 31 Year 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 1964 1962 Expected output 28 January, 1962 29 January, 1964 29 January, 1962 30 January, 1964 30 January, 1962 31 January, 1964 31 January, 1962 14 February, 1964 14 February, 1962 28 February, 1964 Impossible Impossible Impossible Impossible Impossible91

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Software Testin

Cause Effect Graphin Technique Consider sin

le input conditions do not explore

combinations of input circumstances Steps 1. Causes & effects in the specifications are identified. A cause is a distinct input condition or an equivalence class of input conditions. An effect is an output condition or a system transformation. 2. The semantic content of the specification is analysed and transformed into a boolean

raph linkin

the causes & effects. 3. Constraints are imposed 4.

r

aph – limited entry decision table Each column in the table represent a test case. 5. The columns in the decision table are converted into test cases.Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


92

Software Testin

The basic notation for the raph is shown in fi

. 8

Fi .8. 8 : Basic cause effect

raph symbols

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


93

Software Testin

Myers explained this effectively with followin example. “The characters in column

1 must be an A or B. The character in column 2 must be a di it. In this situati

on, the file update is made. If the character in column 1 is incorrect, messa e

x is issued. If the character in column 2 is not a di it, messa

e y is issued”. Th

e causes are c1: character in column 1 is A c2: character in column 1 is B c3: character in column 2 is a di

it and the effects are e1: update made e2: messa

e

x is issued e3: messa e y is issued

94

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Software Testin

Fi . 9: Sample cause effect

raph

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


95

Software Testin

The E constraint states that it must always be true that at most one of c1 or c2 can be 1 (c1 or c2 cannot be 1 simultaneously). The I constraint states that at least one of c1, c2 and c3 must always be 1 (c1, c2 and c3 cannot be 0 simultaneously). The O constraint states that one, and only one, of c1 and c2 must be 1. The constraint R states that, for c1 to be 1, c2 must be 1 (i.e. it is impossible for c1 to be 1 and c2 to be 0),

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


96

Software Testin

Fi . 10: Constraint symbols

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


97

Software Testin

Fi . 11: Symbol for masks constraint

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


98

Software Testin

Fi . 12 : Sample cause effect

raph with exclusive constraint

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


99

Software Testin

Example 8.12Consider the trian

le problem specified in the example 8.3. Draw the Cause effec

t raph and identify the test cases.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


100

Software Testin

Solution The causes are c1: c2: c3: c4: c5: c6: side x is less than sum of sides y and z side y is less than sum of sides x and y side z is less than sum of sides x and y side x is equal to side y side x is equal to side z side y is equal to side z

and effects are e1: Not a trian le e2: Scalene trian

le e3: Isosceles trian

le e

4: Equilateral trian le e5: Impossible sta

e

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


101

Software Testin

The cause effect raph is shown in fi

. 13 and decision table is shown in table

6. The test cases for this problem are available in Table 5.Conditions C1: x < y + z ? C2: y < x + z ? C3: z < x + y ? C4: x = y ? C5: x = z ? C6: y = z ? e1: Not a trian

le e2: Scalene e3: Isosceles e4: Equilateral e5:

Impossible

0 X X X X X 1

1 0 X X X X 1

1 1 0 X X X 1

1 1 1 1 1 1

1 1 1 1 1 0

1 1 1 1 0 1

1 1 1 1 0 0

1 1 1 0 1 1

1 1 1 0 1 0

1 1 1 0 0 1

1 1 1 0 0 0 1

1 1 1 1 1

1

1

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Table 6: Decision table

102

Software Testin

Fi . 13: Cause effect

raph of trian

le problem

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


103

Software Testin

Structural Testin A complementary approach to functional testin

is called stru

ctural / white box testin . It permits us to examine the internal structure of t

he pro ram. Path Testin

Path testin

is the name

iven to a

roup of test techn

iques based on judiciously selectin a set of test paths throu

h the pro

ram. If

the set of paths is properly chosen, then it means that we have achieved some measure of test thorou

hness. This type of testin

involves: 1.

eneratin

a set

of paths that will cover every branch in the pro ram. 2. findin

a set of test c

ases that will execute every path in the set of pro ram paths.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


104

Software Testin

Flow Graph The control flow of a pro ram can be analysed usin

a

raphical repre

sentation known as flow raph. The flow

raph is a directed

raph in which nodes

are either entire statements or fra ments of a statement, and ed

es represents

flow of control.

Fi . 14: The basic construct of the flow

raph

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


105

Software Testin

Fi . 15: Pro

ram for previous date problem

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


110

Software Testin

Fi . 16: Flow

raph of previous date problem

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


111

Software Testin

DD Path Graph Table 7: Mappin of flow

raph nodes and DD path nodes

Flow raph nodes 1 to 9 10 11 12 13,14 15,16,17 18 19 20 21 22 23 DD Path

raph

correspondin node n1 n2 n3 n4 n5 n6 n7 n8 n9 n10 n11 n12 Remarks

There is a sequential flow from node 1 to 9 Decision node, if true o to 13 else

o to 44 Decision node, if true

o to 12 else

o to 19 Decision node, if true

o to 13 else

o to 15 Sequential nodes and are combined to form new node n5 Sequ

ential nodes Ed es from node 14 to 17 are terminated here Decision node, if true

o to 20 else

o to 37 Intermediate node with one input ed

e and one output ed

e Decision node, if true

o to 22 else

o to 27 Intermediate node Decision node,

if true o to 24 else

o to 26

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


112 Cont….

Software Testin

Flow raph nodes 24,25 26 27 28,29 30 31,32 33,34,35 36 37 38,39 40,41,42 43 DD

Path raph correspondin

node n13 n14 n15 n16 n17 n18 n19 n20 n21 n22 n23 n24 Se

quential nodes Two ed es from node 25 & 23 are terminated here Two ed

es from no

de 26 & 21 are terminated here. Also a decision node Sequential nodes Decision node, if true

o to 31 else

o to 33 Sequential nodes Sequential nodes Three ed

e

from node 29,32 and 35 are terminated here Decision node, if true o to 38 else

o to 40 Sequential nodes Sequential nodes Three ed

e from node 36,39 and 42 ar

e terminated here Remarks

Cont….Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


113

Software Testin

Flow raph nodes 44 45 46 47,48,49,50 51 52 53 54 55 56,57 58 59 DD Path

raph c

orrespondin node n25 n26 n27 n28 n29 n30 n31 n32 n33 n34 n35 n36 Remarks

Decision node, if true o to 45 else

o to 82. Three ed

es from 18,43 & 10 are a

lso terminated here. Decision node, if true o to 46 else

o to 77 Decision node

, if true o to 47 else

o to 51 Sequential nodes Decision node, if true

o to 5

2 else o to 68 Intermediate node with one input ed

e & one output e

e Decision

node, if true o to 54 else

o to 59 Intermediate node Decision node, if true

o

to 56 else o to 58 Sequential nodes Two ed

e from node 57 and 55 are terminate

d here Decision node, if true o to 60 else

o to 63. Two ed

e from nodes 58 and

53 are terminated.

Cont….Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


114

Software Testin

Flow raph nodes 60,61,62 63,64,65,66 67 68 69,70,71 72,73,74,75 76 77,78,79 80

81 82,83,84 85 86,87 DD Path raph correspondin

node n37 n38 n39 n40 n41 n42 n4

3 n44 n45 n46 n47 n48 n49 Sequential nodes Sequential nodes Two ed e from node 6

2 and 66 are terminated here Decision node, if true o to 69 else

o to 72 Seque

ntial nodes Sequential nodes Four ed es from nodes 50, 67, 71 and 75 are termina

ted here. Sequential nodes Two ed es from nodes 76 & 79 are terminated here Inte

rmediate node Sequential nodes Two ed es from nodes 81 and 84 are terminated her

e Sequential nodes with exit node Remarks

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


115

Software Testin

Fi . 17: DD path

raph of previous date problem

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


116

Software Testin

Fi . 18: Independent paths of previous date problem

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


117

Software Testin

Example 8.13 Consider the problem for the determination of the nature of roots of a quadratic equation. Its input a triple of positive inte

ers (say a,b,c) and

value may be from interval [0,100]. The pro ram is

iven in fi

. 19. The output

may have one of the followin words: [Not a quadratic equation; real roots; Ima

inary roots; Equal roots] Draw the flow

raph and DD path

raph. Also find indep

endent paths from the DD Path raph.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


118

Software Testin

Fi . 19: Code of quadratic equation problem

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


120

Software Testin

Solution

Fi . 19 (a) : Pro

ram flow

raph

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


121

Software Testin

Fi . 19 (b) : DD Path

raph

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


122

Software Testin

The mappin table for DD path

raph is:

Flow raph nodes 1 to 10 11 12 13 14,15 16 17 18 19 20,21 22 23,24,25 DD Path

r

aph correspondin node A B C D E F G H I J K L Sequential nodes Decision node In

termediate node Decision node Sequential node Two ed es are combined here Two ed

es are combined and decision node Intermediate node Decision node Sequential node Decision node Sequential node Remarks

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


Cont….

123

Software Testin

Flow raph nodes 26,27,28,29 30 31 32,33 34,35,36 37 38,39 DD Path

raph corresp

ondin node M N O P Q R S Sequential nodes Three ed

es are combined Decision nod

e Sequential node Sequential node Three ed es are combined here Sequential nodes

with exit node Remarks

Independent paths are: (i) ABGOQRS (iii) ABCDFGOQRS (v) ABGHIJNRS (vi) ABGHIKMNRS (ii) ABGOPRS (iv) ABCDEFGOPRS (vi) ABGHIKLNRS

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


124

Software Testin

Example 8.14 Consider a pro ram

iven in Fi

.8.20 for the classification of a tr

ian le. Its input is a triple of positive inte

ers (say a,b,c) from the interval

[1,100]. The output may be [Scalene, Isosceles, Equilateral, Not a trian le]. D

raw the flow raph & DD Path

raph. Also find the independent paths from the DD

Path raph.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


125

Software Testin

Fi . 20 : Code of trian

le classification problem

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


127

Software Testin

Solution : Flow raph of trian

le problem is:

Fi .8. 20 (a): Pro

ram flow

raph

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


128

Software Testin

The mappin table for DD path

raph is:

Flow raph nodes DD Path

raph correspondin

node Remarks

1 TO 9 10 11 12, 13 14 15, 16, 17 18 19 20, 21 22 23, 24 25, 26, 27

A B C D E F G H I J K L

Sequential nodes Decision node Decision node Sequential nodes Two ed es are join

ed here Sequential nodes Decision nodes plus joinin of two ed

es Decision node

Sequential nodes Decision node Sequential nodes Sequential nodes

Cont….Software En

ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


129

Software Testin

Flow raph nodes 28 29 30, 31 32, 33, 34 35 36, 37 DD Path

raph correspondin

n

ode Remarks

M N O P Q R

Three ed es are combined here Decision node Sequential nodes Sequential nodes Th

ree ed es are combined here Sequential nodes with exit node

Fi . 20 (b): DD Path

raph

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


130

Software Testin

DD Path raph is

iven in Fi

. 20 (b)

Independent paths are: (i) ABFGNPQR (ii) ABFGNOQR (iii) ABCEGNPQR (iv) ABCDEGNOQR (v) ABFGHIMQR (vi) ABFGHJKMQR (vii)ABFGHJMQR

Fi . 20 (b): DD Path

raph

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


131

Software Testin

Cyclomatic ComplexityMcCabe’s cyclomatic metric V(G) = e – n + 2P. For example, a flow

raph shown in in

Fi . 21 with entry node ‘a’ and exit node ‘f’.

Fi . 21: Flow

raph

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


132

Software Testin

The value of cyclomatic complexity can be calculated as : V(G) = 9 – 6 + 2 = 5 Here e = 9, n = 6 and P =1

There will be five independent paths for the flow raph illustrated in Fi

. 21.

Path 1 : Path 2 : Path 3 : Path 4 : Path 5 : acf abef adcf a b e a c f or a b e a b e f abebef

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


133

Software Testin

Several properties of cyclomatic complexity are stated below:

1. V(G) ≥1 2. V (G) is the maximum number of independent paths in raph G. 3. Inse

rtin & deletin

functional statements to G does not affect V(G). 4. G has only

one path if and only if V(G)=1. 5. Insertin a new row in G increases V(G) by un

ity. 6. V(G) depends only on the decision structure of G.

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


134

Software Testin

The role of P in the complexity calculation V(G)=e-n+2P is required to be understood correctly. We define a flow

raph with unique entry and exit nodes, all nod

es reachable from the entry, and exit reachable from all nodes. This definition would result in all flow

raphs havin

only one connected component. One could,

however, ima ine a main pro

ram M and two called subroutines A and B havin

a fl

ow raph shown in Fi

. 22.

Fi . 22

Software En ineerin

(3rd ed.), By K.K A

arwal & Yo

esh Sin

h, Copyri

ht © New A


135

Software Testin

Let us denote the total raph above with 3 connected components as

V ( M ∪ A ∪ B) = e − n + 2 P= 13�13+2*3 =6This method with P ≠ 1 can

�e used to calculate the complexity of a collection of

programs, particularly a hierarchical nest of su�routines.


�lishers, 2007

136

Software TestingNotice that V ( M ∪ A ∪ B ) = V ( M ) + V ( A) + V ( B ) = 6 . In general, the complexity of a collection C of flow graphs with K connected components is e

�ual to t

he summation of their complexities. To see this let Ci,1 ≤ I ≤ Kdenote the k distinct connected component, and let ei and ni

�e the num

�er of ed

ges and nodes in the ith�connected component. Thenk i =1 k i =1 k i =1 k i =1

V (C ) = e − n + 2 p = ∑ ei − ∑ ni + 2 K = ∑ (ei − ni + 2) = ∑ V (Ci )


�lishers, 2007

137

Software TestingTwo alternate methods are availa

�le for the complexity calculations. 1. Cyclomat

ic complexity V(G) of a flow graph G is e�ual to the num

�er of predicate (decisi

on) nodes plus one. V(G)= ∏ +1 Where ∏ is the num�er of predicate nodes contained in

the flow graph G. 2. Cyclomatic complexity is e�ual to the num

�er of regions of

the flow graph.


�lishers, 2007

138

Software TestingExample 8.15Consider a flow graph given in Fig. 23 and calculate the cyclomatic complexity

�y all three methods.

Fig. 23


�lishers, 2007

139

Software TestingSolution Cyclomatic complexity can

�e calculated

�y any of the three methods. 1.

V(G) = e – n + 2P = 13 – 10 + 2 = 5 2. V(G) =π+1 =4+1=5 3. V(G) = number of regions =5Therefore, com

�lexity value of a flow gra

�h in Fig. 23 is 5.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag


140

Software TestingExam

�le 8.16

Consider the �revious date

�rogram with DD

�ath gra

�h given in Fig. 17. Find cyc

lomatic com�lexity.



141

Software TestingSolutionNumber of edges (e) = 65 Number of nodes (n) =49 (i) (ii) V(G) = e – n + 2P = 65 – 49 + 2 = 18 V(G) = π + 1 = 17 + 1 = 18

(iii) V(G) = Number of regions = 18 The cyclomatic com�lexity is 18.



142


�le 8.17

Consider the quadratic equation �roblem given in exam

�le 8.13 with its DD Path g

ra�h. Find the cyclomatic com

�lexity:



143

Software TestingSolutionNumber of nodes (n) = 19 Number of edges (e) = 24 (i) V(G) = e – n + 2P = 24 – 19 + 2 = 7 (ii) V(G) = π + 1 = 6 + 1 = 7 (iii) V(G) = Number of regions = 7 Hence cyclomatic com

�lexity is 7 meaning thereby, seven inde

�endent

�aths in the DD Path gr

a�h.



144


�le 8.18

Consider the classification of triangle �roblem given in exam

�le 8.14. Find the

cyclomatic com�lexity.



145

Software TestingSolutionNumber of edges (e) = 23 Number of nodes (n) =18 (i) V(G) = e – n + 2P = 23 – 18 + 2 = 7 (ii) V(G) = π + 1 = 6 + 1 = 7 (iii) V(G) = Number of regions = 7 The cyclomatic com

�lexity is 7. Hence, there are seven inde

�endent

�aths as given in exam

�le

8.14.



146

Software TestingGra

�h Matrices

A gra�h matrix is a square matrix with one row and one column for every node in

the gra�h. The size of the matrix (i.e., the number of rows and columns) is equa

l to the number of nodes in the flow gra�h. Some exam

�les of gra

�hs and associat

ed matrices are shown in fig. 24.

Fig. 24 (a): Flow gra�h and gra

�h matrices



147

Software Testing

Fig. 24 (b): Flow gra�h and gra

�h matrices



148

Software Testing

Fig. 24 (c): Flow gra�h and gra

�h matrices



149

Software Testing

Fig. 25 : Connection matrix of flow gra�h shown in Fig. 24 (c)



150

Software Testing

The square matrix re�resent that there are two

�ath ab and cd from node 1 to nod

e 2.



151


�le 8.19 Consider the flow gra

�h shown in the Fig. 26 and draw the gra

�h & c

onnection matrices. Find out cyclomatic com�lexity and two / three link

�aths fr

om a node to any other node.

Fig. 26 : Flow gra�h



152

Software TestingSolution The gra

�h & connection matrices are given below :

To find two link �aths, we have to generate a square of gra

�h matrix [A] and for

three link �aths, a cube of matrix [A] is required.



153

Software Testing



154

Software TestingData Flow TestingData flow testing is another from of structural testing. It has nothing to do with data flow diagrams.

i. ii.

Statements where variables receive values. Statements where these values are used or referenced.

As we know, variables are defined and referenced throughout the �rogram. We may

have few define/ reference anomalies:

i. ii.

A variable is defined but not used/ referenced. A variable is used but never defined.

iii. A variable is defined twice before it is used.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co

�yright © New Ag


155

Software TestingDefinitionsThe definitions refer to a

�rogram P that has a

�rogram gra

�h G(P) and a set of �

rogram variables V. The G(P) has a single entry node and a single exit node. The set of all

�aths in P is PATHS(P) (i) Defining Node: Node n G(P) is a defining

node of the variable v V, written as DEF (v, n), if the value of the variable v is defined at the statement fragment corres

�onding to node n.

(ii) Usage Node: Node n G(P) is a usage node of the variable v V, written as USE (v, n), if the value of the variable v is used at statement fragment corres

�ond

ing to node n. A usage node USE (v, n) is a �redicate use (denote as

�) if state

ment n is a �redicate statement otherwise USE (v, n) is a com

�utation use (denot

ed as c).



156

Software Testing(iii) Definition use: A definition use

�ath with res

�ect to a variable v (denote

d du-�ath) is a

�ath in PATHS(P) such that, for some v V, there are define and u

sage nodes DEF(v, m) and USE(v, n) such that m and n are initial and final nodes of the

�ath. (iv) Definition clear : A definition clear

�ath with res

�ect to a

variable v (denoted dc-�ath) is a definition use

�ath in PATHS(P) with initial a

nd final nodes DEF (v, m) and USE (v, n), such that no other node in the �ath is

a defining node of v. The du-�aths and dc-

�aths describe the flow of data acros

s source statements from �oints at which the values are defined to

�oints at whi

ch the values are used. The du-�aths that are not definition clear are

�otential

trouble s�ots.



157

Software TestingHence, our objective is to find all du-

�aths and then identity those du-

�aths wh

ich are not dc-�aths. The ste

�s are given in Fig. 27. We may like to generate s

�ecific test cases for du-

�aths that are not dc-

�aths.

Fig. 27 : Ste�s for data flow testing



158


�le 8.20 Consider the

�rogram of the determination of the nature of roots of

a quadratic equation. Its in�ut is a tri

�le of

�ositive integers (say a,b,c) an

d values for each of these may be from interval [0,100]. The �rogram is given in

Fig. 19. The out�ut may have one of the o

�tion given below: (i) Not a quadratic

�rogram (ii) real roots (iii) imaginary roots (iv) equal roots (v) invalid in

�u

ts Find all du-�aths and identify those du-

�aths that are definition clear.



159

Software TestingSolution Ste

� I: The

�rogram flow gra

�h is given in Fig. 19 (a). The variables u

sed in the �rogram are a,b,c,d, validin

�ut, D. Ste

� II: DD Path gra

�h is given i

n Fig. 19(b). The cyclomatic com�lexity of this gra

�h is 7 indicating there are

seven inde�endent

�aths. Ste

� III: Define/use nodes for all variables are given

below:Variable Defined at node Used at node 11,13,18,20,24,27,28 11,18,20,24,28 11,18 19,22,23,27 24,28 17,31160

a b c d D Validin�ut

6 8 10 18 23, 27 3, 12, 14



Software TestingSte

� IV: The du-

�aths are identified and are named by their beginning and ending

nodes using Fig. 19 (a).Variablea

Path (beginning, end) nodes

Definition clear ?

6, 11 6, 13 6, 18 6, 20 6, 24 6, 27 6, 28 8, 11 8, 18 8, 20 8, 24 8, 28

Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

b



161

Software TestingVariablec d


Definition clear ?

10, 11 10, 18 18, 19 18, 22 18, 23 18, 27 23, 24 23, 28 27, 24 27, 28 3, 17 3, 31 12, 17 12, 31 14, 17 14, 31

Yes Yes Yes Yes Yes Yes Yes Path not �ossible Path not

�ossible Yes no no no no

yes yes162

D

validin�ut




�le 8.21 Consider the

�rogram given in Fig. 20 for the classification of a t

riangle. Its in�ut is a tri

�le of

�ositive integers (say a,b,c) from the interva

l [1,100]. The out�ut may be: [Scalene, Isosceles, Equilateral, Not a triangle,

Invalid in�uts]. Find all du-

�aths and identify those du-

�aths that are definiti

on clear.



163

Software TestingSolution Ste

� I: The

�rogram flow gra

�h is given in Fig. 20 (a). The variables u

sed in the �rogram are a,b,c, valid in

�ut. Ste

� II: DD Path gra

�h is given in Fi

g. 20(b). The cyclomatic com�lexity of this gra

�h is 7 and thus, there are 7 ind

e�endent

�aths.

Ste� III: Define/use nodes for all variables are given below:

Variable Defined at node Used at node 10, 11, 19, 22 10, 11, 19, 22 10, 11, 19, 22 18, 29

a b c valid in�ut

6 7 9 3, 13, 16



164

Software TestingSte

� IV: The du-

�aths are identified and are named by their beginning and ending

nodes using Fig. 20 (a).Variablea


Definition clear ?

5, 10 5, 11 5, 19 5, 22 7, 10 7, 11 7, 19 7, 22

Yes Yes Yes Yes Yes Yes Yes Yes

b



165

Software TestingVariablec


Definition clear ?

9, 10 9, 11 9, 19 9, 22 3, 18 3, 29 12, 18 12, 29 16, 18 16, 29

Yes Yes Yes Yes no no no no Yes Yes

valid in�ut

Hence total du-�aths are 18 out of which four

�aths are not definition clear



166

Software TestingMutation TestingMutation testing is a fault based technique that is similar to fault seeding, exce�t that mutations to

�rogram statements are made in order to determine

�ro�ert

ies about test cases. it is basically a fault simulation technique. Multi�le co

�ies of a

�rogram are made, and each co

�y is altered; this altered co

�y is called

a mutant. Mutants are executed with test data to determine whether the test data are ca

�able of detecting the change between the original

�rogram and the mutat

ed �rogram. A mutant that is detected by a test case is termed “killed” and the goal

of mutation �rocedure is to find a set of test cases that are able to kill grou�

s of mutant �rograms.



167

Software TestingWhen we mutate code there needs to be a way of measuring the degree to which the code has been modified. For exam

�le, if the original ex

�ression is x+1 and the

mutant for that ex�ression is x+2, that is a lesser change to the original code

than a mutant such as (c*22), where both the o�erand and the o

�erator are change

d. We may have a ranking scheme, where a first order mutant is a single change to an ex

�ression, a second order mutant is a mutation to a first order mutant, an

d so on. High order mutants becomes intractable and thus in �ractice only low or

der mutants are used. One difficulty associated with whether mutants will be killed is the

�roblem of reaching the location; if a mutant is not executed, it can

not be killed. S�ecial test cases are to be designed to reach a mutant. For exam�

le, su��

ose, we have the code. Read (a,b,c); If(a>b) and (b=c) then x:=a*b*c; (make mutants; m1, m2, m3 …….)



168

Software TestingTo execute this, in

�ut domain must contain a value such that a is greater than b

and b equals c. If in�ut domain does not contain such a value, then all mutants

made at this location should be considered equivalent to the original �rogram,

because the statement x:=a*b*c is dead code (code that cannot be reached during execution). If we make the mutant x+y for x+1, then we should take care about the value of y which should not be equal to 1 for designing a test case. The manner by which a test suite is evaluated (scored) via mutation testing is as follows: for a s

�ecified test suite and a s

�ecific set of mutants, there will be three

ty�es of mutants in the code i.e., killed or dead, live, equivalent. The sum of

the number of live, killed, and equivalent mutants will be the total number of mutants created. The score associated with a test suite T and mutants M is sim

�ly

.

# killed ×100% # total − # e�uivalent


�lishers, 2007

169

Software TestingLevels of TestingThere are 3 levels of testing: i. ii. iii. Unit Testing Integration Testing System Testing


�lishers, 2007

170

Software TestingUnit TestingThere are num

�er of reasons in support of unit testing than testing the entire p

roduct.

1. The size of a single module is small enough that we can locate an error fairly easily. 2. The module is small enough that we can attempt to test it in some demonstra

�ly exhaustive fashion. 3. Confusing interactions of multiple errors in

widely different parts of the software are eliminated.


�lishers, 2007

171

Software TestingThere are pro

�lems associated with testing a module in isolation. How do we run

a module without anything to call it, to �e called

�y it or, possi

�ly, to output

intermediate values o�tained during execution? One approach is to construct an

appropriate driver routine to call if and, simple stu�s to

�e called

�y it, and

to insert output statements in it. Stu�s serve to replace modules that are su

�or

dinate to (called �y) the module to

�e tested. A stu

� or dummy su

�program uses t

he su�ordinate module’s interface, may do minimal data manipulation, prints verifi

cation of entry, and returns. This overhead code, called scaffolding represents effort that is import to testing,

�ut does not appear in the delivered product a

s shown in Fig. 29.


�lishers, 2007

172

Software Testing

Fig. 29 : Scaffolding re�uired testing a program unit (module)


�lishers, 2007

173

Software TestingIntegration TestingThe purpose of unit testing is to determine that each independent module is correctly implemented. This gives little chance to determine that the interface

�etw

een modules is also correct, and for this reason integration testing must �e per

formed. One specific target of integration testing is the interface: whether parameters match on

�oth sides as to type, permissi

�le ranges, meaning and utilizat

ion.


�lishers, 2007

174

Software Testing

Fig. 30 : Three different integration approachesSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

175

Software TestingSystem TestingOf the three levels of testing, the system level is closet to everyday experiences. We test many things; a used car

�efore we

�uy it, an on�line ca�le network s

ervice �efore we su

�scri

�e, and so on. A common pattern in these familiar forms

is that we evaluate a product in terms of our expectations; not with respect to a specification or a standard. Conse

�uently, goal is not to find faults,

�ut to

demonstrate performance. Because of this we tend to approach system testing from a functional standpoint rather than from a structural one. Since it is so intuitively familiar, system testing in practice tends to

�e less formal than it migh

t �e, and is compounded

�y the reduced testing interval that usually remains

�ef

ore a delivery deadline. Petschenik gives some guidelines for choosing test cases during system testing.


�lishers, 2007

176

Software TestingDuring system testing, we should evaluate a num

�er of attri

�utes of the software

that are vital to the user and are listed in Fig. 31. These represent the operational correctness of the product and may

�e part of the software specifications

.Usa

�le Secure Compati

�le Dependa

�le Documented Is the product convenient, clear,

and predicta�le? Is access to sensitive data restricted to those with authoriza

tion? Will the product work correctly in conjunction with existing data, software, and procedures? Do ade

�uate safeguards against failure and methods for recove

ry exist in the product? Are manuals complete, correct, and understanda�le?

Fig. 31 : Attri�utes of software to

�e tested during system testing


�lishers, 2007

177

Software TestingValidation Testingo It refers to test the software as a complete product. o This should

�e done af

ter unit & integration testing. o Alpha, �eta & acceptance testing are nothing

�ut the various ways of involving customer during testing.


�lishers, 2007

178

Software TestingValidation Testingo IEEE has developed a standard (IEEE standard 1059�1993) entitled “ IEEE guide for software verification and validation “ to provide specific guidance a

�out planni

ng and documenting the tasks re�uired

�y the standard so that the customer may w

rite an effective plan. o Validation testing improves the �uality of software pr

oduct in terms of functional capa�ilities and

�uality attri

�utes.


�lishers, 2007

179

Software TestingThe Art of De

�ugging

The goal of testing is to identify errors (�ugs) in the program. The process of

testing generates symptoms, and a program’s failure is a clear symptom of the presence of an error. After getting a symptom, we

�egin to investigate the cause and

place of that error. After identification of place, we examine that portion to identify the cause of the pro

�lem. This process is called de

�ugging.

De�ugging Techni

�ues

Pressman explained few characteristics of �ugs that provide some clues. 1. “The sy

mptom and the cause may �e geographically remote. That is, the symptom may appea

r in one part of a program, while the cause may actually �e located in other par

t. Highly coupled program structures may complicate this situation. 2. The symptom may disappear (temporarily) when another error is corrected.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

180

Software Testing3. The symptom may actually

�e caused

�y non errors (e.g. round off inaccuracies

). 4. The symptom may �e caused

�y a human error that is not easily traced. 5. T

he symptom may �e a result of timing pro

�lems rather than processing pro

�lems. 6

. It may �e difficult to accurately reproduce input conditions (e.g. a real time

application in which input ordering is indeterminate). 7. The symptom may �e in

termittent. This is particularly common in em�edded system that couple hardware

with software inextrica�ly. 8. The symptom may

�e due to causes that are distri

�uted across a num

�er of tasks running on different processors”.

181


�lishers, 2007

Software TestingInduction approachLocate the pertinent data Organize the data Devise a hypothesis Prove the hypothesis


�lishers, 2007

182

Software Testing

Fig. 32 : The inductive de�ugging process


�lishers, 2007

183

Software TestingDeduction approachEnumerate the possi

�le causes or hypotheses Use the data to eliminate possi

�le c

auses Refine the remaining hypothesis Prove the remaining hypothesis


�lishers, 2007

184

Software Testing

Fig. 33 : The inductive de�ugging process


�lishers, 2007

185

Software TestingTesting ToolsOne way to improve the

�uality &

�uantity of testing is to make the process as p

leasant as possi�le for the tester. This means that tools should

�e as concise,

powerful & natural as possi�le. The two

�road categories of software testing too

ls are :

Static Dynamic


�lishers, 2007

186

Software TestingThere are different types of tools availa

�le and some are listed

�elow: 1. Stati

c analyzers, which examine programs systematically and automatically. 2. Code inspectors, who inspect programs automatically to make sure they adhere to minimum �uality standards. 3. standards enforcers, which impose simple rules on the dev

eloper. 4. Coverage analysers, which measure the extent of coverage. 5. Output comparators, used to determine whether the output in a program is appropriate or not.


�lishers, 2007

187

Software Testing6. Test file/ data generators, used to set up test inputs. 7. Test harnesses, used to simplify test operations. 8. Test archiving systems, used to provide documentation a

�out programs.


�lishers, 2007

188


�uestions:

8.1 Software testing is: (a) the process of demonstrating that errors are not present (

�) the process of esta

�lishing confidence that a program does what it is

supposed to do (c) the process of executing a program to show it is working as per specifications (d) the process of executing a program with the intent of finding errors 8.2 Software mistakes during coding are known as: (a) failures (

�) de

fects (c) �ugs (d) errors 8.3 Functional testing is known as: (a) Structural tes

ting (c) Regression testing (�) Behavior testing (d) None of the a

�ove

8.4 For a function of n varia�les,

�oundary value analysis yields: (a) 4n+3 test

cases (�) 4n+1 test cases (c) n+4 test cases (d) None of the a

�ove


�lishers, 2007

189

Multiple Choice Questions8.5 For a function of two varia

�les, how many cases will

�e generated

�y ro

�ustn

ess testing? (a) 9 (�) 13 (c) 25 (d) 42 8.6 For a function of n varia

�les ro

�ust

ness testing of �oundary value analysis yields: (a) 4n+1 (

�) 4n+3 (c) 6n+1 (d) N

one of the a�ove 8.7 Regression testing is primarily related to: (a) Functional

testing (�) Data flow testing (c) Development testing (d) Maintenance testing 8.

8 A node with indegree=0 and out degree ≠ 0 is called (a) Source node (�) Destinat

ion node (c) Transfer node (d) None of the a�ove 8.9 A node with indegree ≠ 0 and

out degree=0 is called (a) Source node (�) Predicate node (c) Destination node (

d) None of the a�ove


�lishers, 2007

190

Multiple Choice Questions8.10 A decision ta

�le has (a) Four portions (c) Five portions 8.11 Beta testing

is carried out �y (a) Users (c) Testers (

�) Three portions (d) Two portions (

�)

Developers (d) All of the a�ove

8.12 E�uivalence class partitioning is related to (a) Structural testing (

�) Bla

ck�ox testing (c) Mutation testing (d) All of the a

�ove 8.13 Cause effect graphi

ng techni�ues is one form of (a) Maintenance testing (

�) Structural testing (c)

Function testing (d) Regression testing 8.14 During validation (a) Process is checked (

�) Product is checked (c) Developer’s performance is evaluated (d) The cust

omer checks the productSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

191

Multiple Choice Questions8.15 Verification is (a) Checking the product with respect to customer’s expectation (

�) Checking the product with respect to specifications (c) Checking the prod

uct with respect to the constraints of the project (d) All of the a�ove 8.16 Val

idation is (a) Checking the product with respect to customer’s expectation (�) Che

cking the product with respect to specifications (c) Checking the product with respect to the constraints of the project (d) All of the a

�ove 8.17 Alpha testing

is done �y (a) Customer (

�) Tester (c) Developer (d) All of the a

�ove 8.18 Site

for Alpha testing is (a) Software company (c) Any where (�) Installation place

(d) None of the a�ove

192


�lishers, 2007

Multiple Choice Questions8.19 Site for Beta testing is (a) Software company (c) Any where 8.20 Acceptance testing is done

�y (a) Developers (c) Testers 8.21 One fault may lead to (a) On

e failure (c) Many failure 8.22 Test suite is (a) Set of test cases (c) Set of outputs (

�) User’s site (d) All of the a

�ove (

�) Customers (d) All of the a

�ove (

�)

No failure (d) All of the a�ove (

�) Set of inputs (d) None of the a

�ove

8.23 Behavioral specification are re�uired for: (a) Modeling (

�) Verification (c

) Validation (d) None of the a�ove


�lishers, 2007

193

Multiple Choice Questions8.24 During the development phase, the following testing approach is not adopted (a) Unit testing (

�) Bottom up testing (c) Integration testing (d) Acceptance t

esting 8.25 Which is not a functional testing techni�ue? (a) Boundary value anal

ysis (�) Decision ta

�le (c) Regression testing (d) None of the a

�ove

8.26 Decision ta�le are useful for descri

�ing situations in which: (a) An action

is taken under varying sets of conditions. (�) Num

�er of com

�inations of action

s are taken under varying sets of conditions (c) No action is taken under varying sets of conditions (d) None of the a

�ove 8.27 One weakness of

�oundary value a

nalysis and e�uivalence partitioning is (a) They are not effective (

�) They do n

ot explore com�inations of input circumstances (c) They explore com

�inations of

input circumstances (d) None of the a�ove


�lishers, 2007

194

Multiple Choice Questions8.28 In cause effect graphing techni

�ue, cause & effect are related to (a) Input

and output (�) Output and input (c) Destination and source (d) None of the a

�ov

e 8.29 DD path graph is called as (a) Design to Design Path graph (�) Defect to

Defect Path graph (c) Destination to Destination Path graph (d) Decision to decision Path graph 8.30 An independent path is (a) Any path through the DD path graph that introduce at least one new set of processing statements or new conditions (

�) Any path through the DD path graph that introduce at most one new set of p

rocessing statements or new conditions (c) Any path through the DD path graph that introduce at one and only one new set of processing statements or new conditions (d) None of the a

�ove 8.31 Cyclomatic complexity is developed

�y (a) B.W.Boe

hm (�) T.J.McCa

�e (c) B.W.Lettlewood (d) Victor Basili


�lishers, 2007

195

Multiple Choice Questions8.32 Cyclomatic complexity is denoted

�y (a) V(G)=e�n+2P (�) V(G)= ∏ +1 (c) V(G)=N

um�er of regions of the graph (d) All of the a

�ove 8.33 The e

�uation V(G)= ∏ +1 of

cyclomatic complexity is applica�le only if every predicate node has (a) two ou

tgoing edges (�) three or more outgoing edges (c) no outgoing edges (d) none of

the a�ove 8.34 The size of the graph matrix is (a) Num

�er of edges in the flow g

raph (�) Num

�er of nodes in the flow graph (c) Num

�er of paths in the flow graph

(d) Num�er of independent paths in the flow graph


�lishers, 2007

196

Multiple Choice Questions8.35 Every node is represented

�y (a) One row and one column in graph matrix (

�)

Two rows and two columns in graph matrix (c) One row and two columns in graph matrix (d) None of the a

�ove 8.36 Cyclomatic complexity is e

�ual to (a) Num

�er of

independent paths (c) Num�er of edges 8.37 Data flow testing is related to (a)

Data flow diagrams (c) Data dictionaries (�) Num

�er of paths (d) None of the a

�o

ve (�) E�R diagrams (d) none of the a�ove

8.38 In data flow testing, o�jective is to find (a) All dc�paths that are not du�paths (�) All du�paths (c) All du�paths that are not dc�paths (d) All dc�paths


�lishers, 2007

197

Multiple Choice Questions8.39 Mutation testing is related to (a) Fault seeding (c) Fault checking (

�) Fun

ctional testing (d) None of the a�ove

8.40 The overhead code re�uired to

�e written for unit testing is called (a) Dri

vers (�) Stu

�s (c) Scaffolding (d) None of the a

�ove 8.41 Which is not a de

�uggi

ng techni�ues (a) Core dumps (

�) Traces (c) Print statements (d) Regression test

ing 8.42 A �reak in the working of a system is called (a) Defect (

�) Failure (c)

Fault (d) Error 8.43 Alpha and Beta testing techni�ues are related to (a) Syste

m testing (�) Unit testing (c) acceptance testing (d) Integration testing


�lishers, 2007

198

Multiple Choice Questions8.44 Which one is not the verification activity (a) Reviews (

�) Path testing (c)

Walkthrough (d) Acceptance testing 8.45 Testing the software is �asically (a) V

erification (c) Verification and validation 8.46 Integration testing techni�ues

are (a) Topdown (c) Sandwich (�) Validation (d) None of the a

�ove (

�) Bottom up

(d) All of the a�ove

8.47 Functionality of a software is tested �y (a) White

�ox testing (

�) Black

�o

x testing (c) Regression testing (d) None of the a�ove 8.48 Top down approach is

used for (a) Development (c) Validation (�) Identification of faults (d) Functi

onal testing199


�lishers, 2007

Multiple Choice Questions8.49 Thread testing is used for testing (a) Real time systems (c) Event driven systems (

�) O

�ject oriented systems (d) All of the a

�ove

8.50 Testing of software with actual data and in the actual environment is called (a) Alpha testing (

�) Beta testing (c) Regression testing (d) None of the a

�ov

e


�lishers, 2007

200

Exercises8.1 What is software testing? Discuss the role of software testing during software life cycle and why is it so difficult? 8.2 Why should we test? Who should do the testing? 8.3 What should we test? Comment on this statement. Illustrate the importance of testing 8.4 Defined the following terms: (i) fault (ii) (iii)

�ug

(iv) failure mistake

8.5 What is the difference �etween (i) Alpha testing &

�eta testing (ii) Develop

ment & regression testing (iii) Functional & structural testing 8.6 Discuss the limitation of testing. Why do we say that complete testing is impossi

�le?


�lishers, 2007

201

Exercises8.7 Briefly discuss the following (i) Test case design, Test & Test suite (ii) Verification & Validation (iii) Alpha,

�eta & acceptance testing 8.8 Will exhaust

ive testing (even if possi�le for every small programs) guarantee that the progr

am is 100% correct? 8.9 Why does software fail after it has passed from acceptance testing? Explain. 8.10 What are various kinds of functional testing? Descri

�e

any one in detail. 8.11 What is a software failure? Explain necessary and sufficient conditions for software failure. Mere presence of faults means software failure. Is it true? If not, explain through an example, a situation in which a failure will definitely occur. 8.12 Explain the

�oundary value analysis testing te

chni�ues with the help of an example.


�lishers, 2007

202

Exercises8.13 Consider the program for the determination of next date in a calendar. Its input is a triple of day, month and year with the following range 1 ≤ month ≤ 12 1 ≤ day ≤ 31 1900 1 ≤ year ≤ 2025 The possi

�le outputs would

�e Next date or invalid date.

Design �oundary value, ro

�ust and worst test cases for this programs. 8.14 Discu

ss the difference �etween worst test case and adhoc test case performance evalua

tion �y means of testing. How can we

�e sure that the real worst case has actual

ly �een o

�served? 8.15 Descri

�e the e

�uivalence class testing method. Compare th

is with �oundary value analysis techni

�ues


�lishers, 2007

203

Exercises8.16 Consider a program given

�elow for the selection of the largest of num

�ers


�lishers, 2007

204

Exercises(i) Design the set of test cases using

�oundary value analysis techni

�ue and e

�u

ivalence class testing techni�ue. (ii) Select a set of test cases that will prov

ide 100% statement coverage. (iii) Develop a decision ta�le for this program. 8.

17 Consider a small program and show, why is it practically impossi�le to do exh

austive testing? 8.18 Explain the usefulness of decision ta�le during testing. I

s it really effective? Justify your answer. 8.19 Draw the cause effect graph of the program given in exercise 8.16. 8.20 Discuss cause effect graphing techni

�ue

with an example. 8.21 Determine the �oundary value test cases the extended tria

ngle pro�lem that also considers right angle triangles.


�lishers, 2007

205

Exercises8.22 Why does software testing need extensive planning? Explain. 8.23 What is meant

�y test case design? Discuss its o

�jectives and indicate the steps involved

in test case design. 8.24 Let us consider an example of grading the students in an academic institution. The grading is done according to the following rules:

Generate test cases using e�uivalence class testing techni

�ue


�lishers, 2007

206

Exercises8.25 Consider a program to determine whether a num

�er is ‘odd’ or ‘even’ and print the m

essage NUMBER IS EVEN Or NUMBER IS ODD The num�er may

�e any valid integer. Desi

gn �oundary value and e

�uivalence class test cases. 8.26 Admission to a professi

onal course is su�ject to the following conditions:


�lishers, 2007

207

ExercisesIf aggregate marks of an eligi

�le candidate are more than 225, he/she will

�e el

igi�le for honors course, otherwise he/she will

�e eligi

�le for pass course. The

program reads the marks in the three su�jects and generates the following outpu

ts: (a) Not Eligi�le (

�) Eligi

�le to Pass Course (c) Eligi

�le to Honors Course D

esign test cases using decision ta�le testing techni

�ue. 8.27 Draw the flow grap

h for program of largest of three num�ers as shown in exercise 8.16. Find out al

l independent paths that will guarantee that all statements in the program have �een tested. 8.28 Explain the significance of independent paths. Is it necessary to look for a tool for flow graph generation, if program size increases

�eyond

100 source lines? 8.29 Discuss the structure testing. How is it different form functional testing?Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

208

Exercises8.30 What do you understand

�y structural testing? Illustrate important structur

al testing techni�ues. 8.31 Discuss the importance of path testing during struct

ural testing. 8.32 What is cyclomatic complexity? Explain with the help of an example. 8.33 Is it reasona

�le to define “thresholds” for software modules? For exampl

e, is a module accepta�le if its V(G) ≤ 10? Justify your answer. 8.34 Explain data

flow testing. Consider an example and show all “du” paths. Also identify those “du” paths that are not “dc” paths. 8.35 Discuss the various steps of data flow testing. 8.36 If we pertur

� a value, changing the current value of 100

�y 1000, what is the

effect of this change? What precautions are re�uired while designing the test ca

ses?


�lishers, 2007

209

Exercises8.37 What is the difference

�etween white and

�lack

�ox testing? Is determining

test cases easier in �ack or white

�ox testing? Is it correct to claim that if w

hite �ox testing is done properly, it will achieve close to 100% path coverage?

8.38 What are the o�jectives of testing? Why is the psychology of a testing pers

on important? 8.39 Why does software fail after it has passed all testing phases? Remem

�er, software, unlike hardware does not wear out with time. 8.40 What is

the purpose of integration testing? How is it done? 8.41 Differentiate �etween i

ntegration testing and system testing. 8.42 Is unit testing possi�le or even des

ira�le in all circumstances? Provide examples to Justify your answer? 8.43 Petes

chenik suggested that a different team than the one that does integration testing should carry out system testing. What are some good reasons for this?Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

210

Exercises8.44 Test a program of your choice, and uncover several program errors. Localise the main route of these errors, and explain how you found the courses. Did you use the techni

�ues of Ta

�le 8? Explain why or why not. 8.45 How can design attri�

utes facilitate de�ugging? 8.46 List some of the pro

�lem that could result from

adding de�ugging statements to code. Discuss possi

�le solutions to these pro

�le

ms. 8.47 What are various de�ugging approaches? Discuss them with the help of ex

amples. 8.48 Researchers and practitioners have proposed several mixed testing strategies intended to com

�ine advantages of various techni

�ues discussed in this

chapter. Propose your own com�ination, perhaps also using some kind of random t

esting at selected points. 8.49 Design a test set for a spell checker. Then run it on a word processor having a spell checker, and report on possi

�le inade

�uaci

es with respect to your re�uirements.


�lishers, 2007

211

Exercises8.50 4 GLs represent a major step forward in the development of automatic program generation. Explain the major advantage & disadvantage in the use of 4 GLs. What are the cost impact of applications of testing and how do you justify expenditures for these activities.


�lishers, 2007

212


�lishers, 2007

1

Software MaintenanceWhat is Software Maintenance?Software Maintenance is a very

�road activity that includes error corrections, e

nhancements of capa�ilities, deletion of o

�solete capa

�ilities, and optimization

.


�lishers, 2007

2

Software MaintenanceCategories of MaintenanceCorrective maintenanceThis refer to modifications initiated

�y defects in the software.

Adaptive maintenanceIt includes modifying the software to match changes in the ever changing environment.

Perfective maintenanceIt means improving processing efficiency or performance, or restructuring the software to improve changea

�ility. This may include enhancement of existing system

functionality, improvement in computational efficiency etc.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

3

Software MaintenanceOther types of maintenanceThere are long term effects of corrective, adaptive and perfective changes. This leads to increase in the complexity of the software, which reflect deteriorating structure. The work is re

�uired to

�e done to maintain it or to reduce it, if

possi�le. This work may

�e named as preventive maintenance.


�lishers, 2007

4

Software MaintenanceCorr ectiv e (2 1% )

Perfective Adaptive Preventive Corrective

Prev

ent iv e(

4% )

Perf e ct ive (50% )

Ada p tive ( 2

5%)

Fig. 1: Distri�ution of maintenance effort


�lishers, 2007

5

Software MaintenancePro

�lems During Maintenance

Often the program is written �y another person or group of persons.

Often the program is changed �y person who did not understand it clearly. Progra

m listings are not structured. High staff turnover. Information gap. Systems are not designed for change.


�lishers, 2007

6

Software MaintenanceMaintenance is Managea

�le

A common misconception a�out maintenance is that it is not managea

�le. Report of

survey conducted �y Lientz & Swanson gives some interesting o

�servations:

1 2 3 4 5 6 7 8 Emergency de�ugging Routine de

�ugging Data environment adaptatio

n Changes in hardware and OS Enhancements for users Documentation Improvement Code efficiency improvement Others 12.4% 9.3% 17.3% 6.2% 41.8% 5.5% 4.0% 3.5%

Ta�le 1: Distri

�ution of maintenance effort


�lishers, 2007

7

Software MaintenanceKinds of maintenance re

�uests

1 2 3 4 5 6 New reports Add data in existing reports Reformed reports Condense reports Consolidate reports Others 40.8% 27.1% 10% 5.6% 6.4% 10.1%

Ta�le 2: Kinds of maintenance re

�uests


�lishers, 2007

8

Software MaintenancePotential Solutions to Maintenance Pro

�lems

Budget and effort reallocation Complete replacement of the system Maintenance of existing system


�lishers, 2007

9

Software MaintenanceThe Maintenance Process

Fig. 2: The software maintenance process


�lishers, 2007

10

Software MaintenanceProgram UnderstandingThe first phase consists of analyzing the program in order to understand.

Generating Particular Maintenance ProposalThe second phase consists of generating a particular maintenance proposal to accomplish the implementation of the maintenance o

�jective.

Ripple EffectThe third phase consists of accounting for all of the ripple effect as a conse

�u

ence of program modifications.


�lishers, 2007

11

Software MaintenanceModified Program TestingThe fourth phase consists of testing the modified program to ensure that the modified program has at least the same relia

�ility level as

�efore.

Maintaina�ility

Each of these four phases and their associated software �uality attri

�utes are c

ritical to the maintenance process. All of these factors must �e com

�ined to for

m maintaina�ility.


�lishers, 2007

12

Software MaintenanceMaintenance ModelsQuick�fix ModelThis is

�asically an adhoc approach to maintaining software. It is a fire fighti

ng approach, waiting for the pro�lem to occur and then trying to fix it as

�uick

ly as possi�le. Pro

�lem found

Fix itFig. 3: The

�uick�fix model


�lishers, 2007

13

Software MaintenanceIterative Enhancement ModelAnalysis Characterization of proposed modifications Redesign and implementation


�lishers, 2007

14

Software MaintenanceAnalyze existing system

Redesign current version and implementation

Characterize proposed modifications

Fig. 4: The three stage cycle of iterative enhancement


�lishers, 2007

15

Software MaintenanceReuse Oriented ModelThe reuse model has four main steps: 1. Identification of the parts of the old system that are candidates for reuse. 2. Understanding these system parts. 3. Modification of the old system parts appropriate to the new re

�uirements. 4. Integr

ation of the modified parts into the new system.


�lishers, 2007

16

Software MaintenanceOld system New system

Re�uirements analysis Design Source code Test data Components li

�rary

Re�uirements analysis Design Source code Test data

Fig. 5: The reuse model17


�lishers, 2007

Software MaintenanceBoehm’s ModelBoehm proposed a model for the maintenance process

�ased upon the economic model

s and principles. Boehm represent the maintenance process as a closed loop cycle.


�lishers, 2007

18

Software MaintenanceManagement decisions

Proposed changes Evaluation Results

Approved changes Change implementation New version of software

Fig. 6: Boehm’s model


�lishers, 2007

19

Software MaintenanceTaute Maintenance ModelIt is a typical maintenance model and has eight phases in cycle fashion. The phases are shown in Fig. 7

Fig. 7: Taute maintenance modelSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

20

Software MaintenancePhases : 1. Change re

�uest phase 2. Estimate phase 3. Schedule phase 4. Programm

ing phase 5. Test phase 6. Documentation phase 7. Release phase 8. Operation phaseSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

21

Software MaintenanceEstimation of maintenance costs

Phase Analysis Design Implementation

Ratio 1 10 100

Ta�le 3: Defect repair ratio


�lishers, 2007

22

Software MaintenanceBelady and Lehman ModelM = P + Ke (c�d)where

M : Total effort expended P : Productive effort that involves analysis, design, coding, testing and evaluation. K : An empirically determined constant. c : Complexity measure due to lack of good design and documentation. d : Degree to which maintenance team is familiar with the software.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

23

Software MaintenanceExample – 9.1 The development effort for a software project is 500 person months. The empirically determined constant (K) is 0.3. The complexity of the code is

�u

ite high and is e�ual to 8. Calculate the total effort expended (M) if (i) maint

enance team has good level of understanding of the project (d=0.9) (ii) maintenance team has poor understanding of the project (d=0.1)


�lishers, 2007

24

Software MaintenanceSolution Development effort (P) = 500 PM K = 0.3 C=8 (i) maintenance team has good level of understanding of the project (d=0.9) M = P + Ke (c�d) = 500 + 0.3e(8�0.9) = 500 + 363.59 = 863.59 PM (ii) maintenance team has poor understanding of the project (d=0.1) M = P + Ke (c�d) = 500 + 0.3e(8�0.1) = 500 + 809.18 = 1309.18 PMSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

25

Software MaintenanceBoehm ModelBoehm used a

�uantity called Annual Change Traffic (ACT). “The fraction of a softw

are product’s source instructions which undergo change during a year either through addition, deletion or modification”.

KLOCadded + KLOCdeleted ACT = KLOCtotalAME = ACT x SDE Where, SDE : Software development effort in person months ACT : Annual change Traffic EAF : Effort Adjustment Factor AME = ACT * SDE * EAFSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

26

Software MaintenanceExample – 9.2 Annual Change Traffic (ACT) for a software system is 15% per year. The development effort is 600 PMs. Compute estimate for Annual Maintenance Effort (AME). If life time of the project is 10 years, what is the total effort of the project ?


�lishers, 2007

27

Software MaintenanceSolution The development effort = 600 PM Annual Change Traffic (ACT) = 15% Total duration for which effort is to

�e calculated = 10 years The maintenance effort

is a fraction of development effort and is assumed to �e constant. AME = ACT x

SDE = 0.15 x 600 = 90 PM Maintenance effort for 10 years Total effort = 10 x 90 = 90 PM = 600 + 900 = 1500 PM


�lishers, 2007

28

Software MaintenanceExample – 9.3 A software project has development effort of 500 PM. It is assumed that 10% code will

�e modified per year. Some of the cost multipliers are given a

s: 1. Re�uired software Relia

�ility (RELY) : high 2. Date

�ase size (DATA) : hig

h 3. Analyst capa�ility (ACAP) : high 4. Application experience (AEXP) : Very hi

gh 5. Programming language experience (LEXP) : high Other multipliers are nominal. Calculate the Annual Maintenance Effort (AME).


�lishers, 2007

29

Software MaintenanceSolution Annual change traffic (ACT) = 10% Software development effort (SDE) = 500 Pm Using Ta

�le 5 of COCOMO model, effort adjustment factor can

�e calculated

given �elow : RELY = 1.15 ACAP = 0.86 AEXP = 0.82 LEXP = 0.95 DATA = 1.08


�lishers, 2007

30

Software MaintenanceOther values are nominal values. Hence, EAF = 1.15 x 0.86 x 0.82 x 0.95 x 1.08 = 0.832 AME = ACT * SDE * EAF = 0.1 * 500 * 0.832 = 41.6 PM AME = 41.6 PM


�lishers, 2007

31

Software MaintenanceRegression TestingRegression testing is the process of retesting the modified parts of the software and ensuring that no new errors have

�een introduced into previously test code

. “Regression testing tests �oth the modified code and other parts of the program

that may �e affected

�y the program change. It serves many purposes : increase c

onfidence in the correctness of the modified program locate errors in the modified program preserve the

�uality and relia

�ility of software ensure the software’s

continued operationSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

32

Software MaintenanceDevelopment Testing Versus Regression TestingSr. No. 1. 2. 3. 4. 5. Development testing Regression testing

We create test suites and test plans We test all software components

We can make use of existing test suite and test plans We retest affected components that have

�een modified

�y modifications. Budget often does not give time fo

r regression testing. We perform regression testing many times over the life of the software product. Performed in crisis situations, under greater time constraints.33

Budget gives time for testing We perform testing just once on a software product Performed under the pressure of release date of the software


�lishers, 2007

Software MaintenanceRegression Test SelectionRegression testing is very expensive activity and consumes significant amount of effort / cost. Many techni

�ues are availa

�le to reduce this effort/ cost. 1. Re

use the whole test suite 2. Reuse the existing test suite, �ut to apply a regres

sion test selection techni�ue to select an appropriate su

�set of the test suite

to �e run.


�lishers, 2007

34

Software MaintenanceFragment A S1 S2 S3 S4 S5 y = (x � 1) * (x + 1) if (y = 0) return (error) else S1’ S2’ S3’ S4’ S5’ Fragment B (modified form of A) y = (x �1) * (x + 1) if (y = 0) return (error) else

�1� return � � � y� � �

� 1 � return � � y − 3� � � �

Fig. 8: code fragment A and B


�lishers, 2007

35

Software MaintenanceTest cases Test num

�er t1 t2 t3 t4 Input x=1 x = �1 x=2 x=0 Execution History S1

, S2, S3 S1, S2, S3 S1, S2, S5 S1, S2, S5

Fig. 9: Test cases for code fragment A of Fig. 8


�lishers, 2007

36

Software MaintenanceIf we execute all test cases, we will detect this divide

�y zero fault. But we h

ave to minimize the test suite. From the fig. 9, it is clear that test cases t3 and t4 have the same execution history i.e. S1, S2, S5. If few test cases have the same execution history; minimization methods select only one test case. Hence, either t3 or t4 will

�e selected. If we select t4 then fine otherwise fault no

t found. Minimization methods can omit some test cases that might expose fault in the modified software and so, they are not safe. A safe regression test selection techni

�ue is one that, under certain assumptions, selects every test case fr

om the original test suite that can expose faults in the modified program.


�lishers, 2007

37

Software MaintenanceSelective Retest Techni

�ues

Selective retest techni�ues may

�e more economical than the “retest�all” techni�ue.

Selective retest techni�ues are

�roadly classified in three categories : 1. Cove

rage techni�ues : They are

�ased on test coverage criteria. They locate covera

�l

e program components that have �een modified, and select test cases that exercis

e these components. 2. Minimization techni�ues: They work like coverage techni

�u

es, except that they select minimal sets of test cases. 3. Safe techni�ues: They

do not focus on coverage criteria; instead they select every test case that cause a modified program to produce different output than its original version.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

38

Software MaintenanceRothermal identified categories in which regression test selection techni

�ues ca

n �e compared and evaluated. These categories are: Inclusiveness measures the ex

tent to which a techni�ue chooses test cases that will cause the modified progra

m to produce different output than the original program, and there�y expose faul

ts caused �y modifications. Precision measures the a

�ility of a techni

�ue to avo

id choosing test cases that will not cause the modified program to produce different output than the original program. Efficiency measures the computational cost, and thus, practically, of a techni

�ue. Generality measures the a

�ility of a t

echni�ue to handle realistic and diverse language constructs, ar

�itrarily comple

x modifications, and realistic testing applications.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

39

Software MaintenanceReverse EngineeringReverse engineering is the process followed in order to find difficult, unknown and hidden information a

�out a software system.


�lishers, 2007

40

Software MaintenanceScope and TasksThe areas there reverse engineering is applica

�le include (

�ut not limited to):

1. Program comprehension 2. Redocumentation and/ or document generation 3. Recovery of design approach and design details at any level of a

�straction 4. Identif

ying reusa�le components 5. Identifying components that need restructuring 6. Re

covering �usiness rules, and 7. Understanding high level system description


�lishers, 2007

41

Software MaintenanceReverse Engineering encompasses a wide array of tasks related to understanding and modifying software system. This array of tasks can

�e �roken into a num

�er of

classes.

Mapping �etween application and program domains

Pro�lem/ application domain

Mapping

Programming/ implement domain

Fig. 10: Mapping �etween application and domains program


�lishers, 2007

42

Software MaintenanceMapping

�etween concrete and a

�stract levels Rediscovering high level structures

Finding missing semantics links �etween program syntax and

To extract reusa�le component


�lishers, 2007

43

Software MaintenanceLevels of Reverse EngineeringReverse Engineers detect low level implementation constructs and replace them with their high level counterparts. The process eventually results in an incremental formation of an overall architecture of the program.


�lishers, 2007

44

Software Maintenance

Fig. 11: Levels of a�straction


�lishers, 2007

45

Software MaintenanceRedocumentationRedocumentation is the recreation of a semantically representation within the same relative a

�straction level. e

�uivalent

Design recoveryDesign recovery entails identifying and extracting meaningful higher level a

�str

actions �eyond those o

�tained directly from examination of the source code. This

may �e achieved from a com

�ination of code, existing design documentation, pers

onal experience, and knowledge of the pro�lem and application domains.


�lishers, 2007

46

Software MaintenanceSoftware RE�EngineeringSoftware re�engineering is concerned with taking existing legacy systems and re�implementing them to make them more maintaina

�le. The critical distinction

�etwe

en re�engineering and new software development is the starting point for the development as shown in Fig.12.


�lishers, 2007

47

Software MaintenanceSystem specification Existing software system

Design and implementation

Understanding and transformation

New system

Re�engineered systemFig. 12: Comparison of new software development with re�engineeringSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

48

Software MaintenanceThe following suggestions may

�e useful for the modification of the legacy code:

Study code well �efore attempting changes Concentrate on overall control flow a

nd not coding Heavily comment internal code Create Cross References Build Sym�ol

ta�les Use own varia

�les, constants and declarations to localize the effect Kee

p detailed maintenance document Use modern design techni�ues


�lishers, 2007

49

Software MaintenanceSource Code Translation1. Hardware platform update: The organization may wish to change its standard hardware platform. Compilers for the original language may not

�e availa

�le on the

new platform. 2. Staff Skill Shortages: There may �e lack of trained maintenanc

e staff for the original language. This is a particular pro�lem where programs w

ere written in some non standard language that has now gone out of general use. 3. Organizational policy changes: An organization may decide to standardize on a particular language to minimize its support software costs. Maintaining many versions of old compilers can

�e very expensive.


�lishers, 2007

50

Software MaintenanceProgram Restructuring1. Control flow driven restructuring: This involves the imposition of a clear control structure within the source code and can

�e either inter modular or intra

modular in nature. 2. Efficiency driven restructuring: This involves restructuring a function or algorithm to make it more efficient. A simple example is the replacement of an IF�THEN�ELSE�IF�ELSE construct with a CASE construct.Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

51


Fig. 13: Restructuring a program


�lishers, 2007

52

Software Maintenance3. Adaption driven restructuring: This involves changing the coding style in order to adapt the program to a new programming language or new operating environment, for instance changing an imperative program in PASCAL into a functional program in LISP.


�lishers, 2007

53

Software MaintenanceConfiguration ManagementThe process of software development and maintenance is controlled is called configuration management. The configuration management is different in development and maintenance phases of life cycle due to different environments.

Configuration Management ActivitiesThe activities are divided into four

�road categories. 1. The identification of

the components and changes 2. The control of the way �y which the changes are ma

de 3. Auditing the changes 4. Status accounting recording and documenting all the activities that have take placeSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

54

Software MaintenanceThe following documents are re

�uired for these activities Project plan Software

re�uirements specification document Software design description document Source

code listing Test plans / procedures / test cases User manuals


�lishers, 2007

55

Software MaintenanceSoftware VersionsTwo types of versions namely revisions (replace) and variations (variety). Version Control : A version control tool is the first stage towards

�eing a

�le to man

age multiple versions. Once it is in place, a detailed record of every version of the software must

�e kept. This comprises the Name of each source code compone

nt, including the variations and revisions The versions of the various compilers and linkers used The name of the software staff who constructed the component The date and the time at which it was constructedSoftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu

�lishers, 2007

56

Software MaintenanceChange Control ProcessChange control process comes into effect when the software and associated documentation are delivered to configuration management change re

�uest form (as shown

in fig. 14), which should record the recommendations regarding the change.


�lishers, 2007

57


Fig. 14: Change re�uest form


�lishers, 2007

58

Software MaintenanceDocumentationSoftware documentation is the written record of the facts a

�out a software syste

m recorded with the intent to convey purpose, content and clarity.


�lishers, 2007

59

Software MaintenanceUser DocumentationS.No. 1. 2. Document System Overview Installation Guide Function Provides general description of system’s functions. Descri

�es how to set up the system, customize

it to local hardware needs and configure it to particular hardware and other software systems. Provides simple explanations of how to start using the system. Provides in depth description of each system facility and how it can

�e used. Boo

klet Contains a summary of new features. Serves as a factual lookup. Provides information on services such as networking, security and upgrading.

3. 4. 5. 6. 7.

Beginner’s Guide Reference Guide Enhancement Quick reference card System administration

Ta�le 5: User Documentation


�lishers, 2007

60

Software MaintenanceSystem DocumentationIt refers to those documentation containing all facets of system, including analysis, specification, design, implementation, testing, security, error diagnosis and recovery.


�lishers, 2007

61

Software MaintenanceSystem DocumentationS.No. 1. 2. Document System Rationale SRS Function Descri

�es the o

�jectives of t

he entire system. Provides information on exact re�uirements of system as agreed

�etween user and developers. Provides description of: (i) How system re

�uiremen

ts are implemented. (ii) How the system is decomposed into a set of interacting program units. (iii) The function of each program unit. Provides description of: (i) How the detailed system design is expressed in some formal programming language. (ii) Program actions in the form of intra program comments.62

3.

Specification/ Design

4.

Implementation


�lishers, 2007

Software MaintenanceS.No. 5. Document System Test Plan Function Provides description of how program units are tested individually and how the whole system is tested after integration. Descri

�es the tests that the system must pass

�efore users accept it. Contai

ns description of all terms that relate to the software system in �uestion.

6.

Acceptance Test Plan

7.

Data Dictionaries

Ta�le 6: System Documentation


�lishers, 2007

63


�uestions:

9.1 Process of generating analysis and design documents is called (a) Inverse Engineering (

�) Software Engineering (c) Reverse Engineering (d) Re�engineering 9.

2 Regression testing is primarily related to (a) Functional testing (�) Data flo

w testing (c) Development testing (d) Maintenance testing 9.3 Which one is not a category of maintenance ? (a) Corrective maintenance (

�) Effective maintenance

(c) Adaptive maintenance (d) Perfective maintenance 9.4 The maintenance initiated �y defects in the software is called (a) Corrective maintenance (

�) Adaptive m

aintenance (c) Perfective maintenance (d) Preventive maintenance 9.5 Patch is known as (a) Emergency fixes (c) Critical fixes (

�) Routine fixes (d) None of the

a�ove

64

Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu�l

ishers

Multiple Choice Questions9.6 Adaptive maintenance is related to (a) Modification in software due to failure (

�) Modification in software due to demand of new functionalities (c) Modific

ation in software due to increase in complexity (d) Modification in software to match changes in the ever�changing environment.9.7 Perfective maintenance refers to enhancements (a) Making the product

�etter

(�) Making the product faster and smaller (c) Making the product with new functi

onalities (d) All of the a�ove 9.8 As per distri

�ution of maintenance effort, wh

ich type of maintenance has consumed maximum share? (a) Adaptive (�) Corrective

(c) Perfective (d) Preventive 9.9 As per distri�ution of maintenance effort, whi

ch type of maintenance has consumed minimum share? (a) Adaptive (�) Corrective (

c) Perfective (d) PreventiveSoftware Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu

�l

ishers 65

Multiple Choice Questions9.10 Which one is not a maintenance model ? (a) CMM (

�) Iterative Enhancement mo

del (c) Quick�fix model (d) Reuse�Oriented model 9.11 In which model, fixes are done without detailed analysis of the long�term effects? (a) Reuse oriented model (

�) Quick�fix model (c) Taute maintenance model (d) None of the a�ove 9.12 Ite

rative enhancement model is a (a) three stage model (c) four stage model 9.13 Taute maintenance model has (a) Two phases (c) eight phases 9.14 In Boehm model, ACT stands for (a) Actual change time (c) Annual change traffic (

�) two stage mod

el (d) seven stage model (�) six phases (d) ten phases (

�) Actual change traffic

(d) Annual change time66


ishers

Multiple Choice Questions9.15 Regression testing is known as (a) the process of retesting the modified parts of the software (

�) the process of testing the design documents (c) the proc

ess of reviewing the SRS (d) None of the a�ove 9.16 The purpose of regression te

sting is to (a) increase confidence in the correctness of the modified program (�) locate errors in the modified program (c) preserve the

�uantity and relia

�ili

ty of software (d) All of the a�ove 9.17 Regression testing is related to (a) ma

intenance of software (c) �oth (a) and (

�) (

�) development of software (d) none

of the a�ove.

9.18 Which one is not a selective retest techni�ue (a) coverage techni

�ue (

�) mi

nimization techni�ue (c) safe techni

�ue (d) maximization techni

�ue


ishers 67

Multiple Choice Questions9.19 Purpose of reverse engineering is to (a) recover information from the existing code or any other intermediate document (

�) redocumentation and/or document

generation (c) understand the source code and associated documents (d) All of the a

�ove 9.20 Legacy systems are (a) old systems (c) undeveloped systems 9.21 Use

r documentation consists of (a) System overview (c) Reference guide (�) new syst

ems (d) None of the a�ove (

�) Installation guide (d) All of the a

�ove

9.22 Which one is not a user documentations ? (a) Beginner’s Guide (�) Installatio

n guide (c) SRS (d) System administration


ishers

68

Multiple Choice Questions9.23 System documentation may not have (a) SRS (c) Acceptance Test Plan (

�) Desi

gn document (d) System administration

9.24 The process �y which existing processes and methods are replaced

�y new tec

hni�ues is: (a) Reverse engineering (

�) Business process re�engineering (c) Soft

ware configuration management (d) Technical feasi�ility 9.25 The process of tran

sforming a model into source code is (a) Reverse Engineering (�) Forward enginee

ring (c) Re�engineering (d) RestructuringSoftware Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu

�l

ishers

69

Exercises9.1 What is software maintenance? Descri

�e various categories of maintenance. Wh

ich category consumes maximum effort and why? 9.2 What are the implication of maintenance for a one person software production organisation? 9.3 Some people feel that “maintenance is managea

�le”. What is your opinion a

�out this issue? 9.4 Discu

ss various pro�lems during maintenance. Descri

�e some solutions to these pro

�lem

s. 9.5 Why do you think that the mistake is fre�uently made of considering softw

are maintenance inferior to software development? 9.6 Explain the importance of maintenance. Which category consumes maximum effort and why? 9.7 Explain the steps of software maintenance with help of a diagram. 9.8 What is self descriptiveness of a program? Explain the effect of this parameter on maintenance activities.Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu

�l

ishers 70

Exercises9.9 What is ripple effect? Discuss the various aspects of ripple effect and how does it affect the sta

�ility of a program? 9.10 What is maintaina

�ility? What is

its role during maintenance? 9.11 Descri�e Quick�fix model. What are the advant

age and disadvantage of this model? 9.12 How iterative enhancement model is helpful during maintenance? Explain the various stage cycles of this model. 9.13 Explain the Boehm’s maintenance model with the help of a diagram. 9.14 State the various steps of reuse oriented model. Is it a recommended model in o

�ject oriented

design? 9.15 Descri�e the Taute maintenance model. What are various phases of th

is model? 9.16 Write a short note on Boledy and Lehman model for the calculation of maintenance effort.Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu

�l

ishers 71

Exercises9.17 Descri

�e various maintenance cost estimation model.s 9.18 The development e

ffort for a project is 600 PMs. The empirically determined constant (K) of Belady and Lehman model is 0.5. The complexity of code is

�uite high and is e

�ual to

7. Calculate the total effort expended (M) if maintenance team has reasona�le le

vel of understanding of the project (d=0.7). 9.19 Annual change traffic (ACT) in a software system is 25% per year. The initial development cost was Rs. 20 lacs. Total life time for software is 10 years. What is the total cost of the software system? 9.20 What is regression testing? Differentiate

�etween regression and

development testing? 9.21 What is the importance of regression test selection? Discuss with help of examples. 9.22 What are selective retest techni

�ues? How ar

e they different from “retest�all” techni�ues?Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu

�l

ishers 72

Exercises9.23 Explain the various categories of retest techni

�ues. Which one is not usefu

l and why? 9.24 What are the categories to evaluate regression test selection techni

�ues? Why do we use such categorisation? 9.25 What is reverse engineering? D

iscuss levels of reverse engineering. 9.26 What are the appropriate reverse engineering tools? Discuss any two tools in detail. 9.27 Discuss reverse engineering and re�engineering. 9.28 What is re�engineering? Differentiate �etween re�engineering and new development. 9.29 Discuss the suggestions that may

�e useful for

the modification of the legacy code. 9.30 Explain various types of restructuring techni

�ues. How does restructuring help in maintaining a program?


ishers 73

Exercises9.31 Explain why single entry, single exit modules make testing easier during maintenance. 9.32 What are configuration management activities? Draw the performa of change re

�uest form. 9.33 Explain why the success of a system depends heavily

on the �uantity of the documentation generated during system development. 9.34

What is an appropriate set of tools and documents re�uired to maintain large sof

tware product/ 9.35 Explain why a high degree of coupling among modules can make maintenance very difficult. 9.36 Is it feasi

�le to specify maintaina

�ility in t

he SRS? If yes, how would we specify it? 9.37 What tools and techni�ues are avai

la�le for software maintenance? Discuss any two of them.


ishers

74

Exercises9.38 Why is maintenance programming

�ecoming more challenging than new developme

nt? What are desira�le characteristics of a maintenance programmer? 9.39 Why lit

tle attention is paid to maintaina�ility during design phase? 9.40 List out syst

em documentation and also explain their purpose.


ishers

75

53971072 21378403 Software Engineering by K K Aggarwal YogeshSingh Full Notes

Documents

Transcript of 53971072 21378403 Software Engineering by K K Aggarwal YogeshSingh Full Notes