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%
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
4
The Evolving Role of Software
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”.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
5
The Evolving Role of Software
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
8
Factors Contributing to the Software Crisis• Larger problems,
• Lack of adequate training in software engineering, • Increasing skill shortage,
• Low productivity improvements.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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!
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
20
What is software?• Computer programs documentation and associated
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
29
Software Process• Wrong motivations • Insufficient commitmentImproved future state Initial state state Productivity Process improvement begins
Do not quit here! Learning curve
Time
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 !
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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!
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
38
Software Myths (Management Perspectives)
Software is easy to change
The reality is totally different.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
39
Software Myths (Management Perspectives)
Computers provide greater reliability than the devices they replace
This is not always true.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
41
Software Myths (Customer Perspectives)
Software with more features is better software Software can work right the first time
Both are only myths!
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
42
Software Myths (Developer Perspectives)
Once the software is demonstrated, the job is done.
Usually, the problems just begin!
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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!
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
45
Software Myths (Developer Perspectives)
Aim is to develop working programs
Those days are over. Now objective is to develop good quality maintainable programs!
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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)
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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”.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
55
Role of Management in Software DevelopmentPeople
1
Project
4
Dependency Order
2
Product
3 Process
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
64
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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”
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
17
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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”.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
15
Evolutionary Process ModelConcurr ent activities Initial version
Specification
Outline description
Development
Intermediate versions
Validation
Final version
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
17
Prototyping Model
• Linear model • “Rapid”
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
19
Spiral Model
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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).
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
32
Outcomes of Construction PhaseTest Outline Documentation manuals Software product Construction
Operational manuals Test Suite A description of the current release
User manuals
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
34
Outcomes of Transition Phase
Transition
Product release
Beta test reports
User feedback
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
38
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
48
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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”?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
24
Requirements ElicitationSteps1. Identify stakeholders 2. List out requirements 3. Degree of importance to each requirement.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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)
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
101
Requirements DocumentationNature of SRSBasic Issues • • • • • Functionality External Interfaces Performance Attributes Design constraints imposed on an Implementation
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
103
Requirements DocumentationRanked for important and/or stability Verifiable Modifiable Traceable
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
111
Requirements Validation
SRS document List of problems Organizational standards Validation process
Organizational knowledge
Approved actions
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
114
Review ChecklistsRedundancy Completeness Ambiguity Consistency Organization Conformance Traceability
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
115
PrototypingValidation prototype should be reasonably complete & efficient & should be used as the required system.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
117
Requirements Management Planning• Very critical. • Important for the success of any project.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
118
Requirements Change Management• Allocating adequate resources • Analysis of requirements • Documenting requirements • Requirements traceability • Establishing team communication • Establishment of baseline
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
119
Download from
Q:\IRM\PRIVATE\INITIATIATI\QA\QAPLAN\SRSPLAN.DOC
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
132
Multiple Choice Questions3.23 APIs stand for: (a) Application performance interfaces (b) Application programming interfaces (c) Application programming integration (d) Application performance integration
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
139
Exercises3.36. Discuss the difference between the following: (a) Functional & nonfunctional requirements (b) User & system requirements
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
140
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
30
�oftware Project PlanningRelative Cost of
�oftware Phases�
oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh �ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
33
�oftware Project PlanningMODEL
��tatic,
�ingle Variable Models�
tatic, Multivariable Models�oftware Engineering (3rd ed.), By K.K Aggarwal & Yogesh
�ingh, Copyright © New Ag
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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 ?
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
76
Sof�ware Projec
� Planning
Table 9 (b): For repor�s
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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�.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�)
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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)
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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):
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
98
Sof�ware Projec
� Planning
vi. Facili�ies (FCIL): This depends on
�wo Pos
� Archi
�ec�ure Cos
� Drivers, which
are TOOL and SITE.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
104
Sof�ware Projec
� Planning
= 194.41 * [1.29 x 0.83) = 194.41 x 1.07 = 208.155 Person mon�hs
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
106
Sof�ware Projec
� Planning
Table 16: Pos� Archi
�ec�ure Cos
� Driver ra
�ing level summary
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
Con�…
107
Sof�ware Projec
� Planning
Table 16: Pos� Archi
�ec�ure Cos
� Driver ra
�ing level summary
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
Con�…
108
Sof�ware Projec
� Planning
Table 16: Pos� Archi
�ec�ure Cos
� Driver ra
�ing level summary
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
Con�…
109
Sof�ware Projec
� Planning
Table 16: Pos� Archi
�ec�ure Cos
� Driver ra
�ing level summary
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Table 17: Module complexi�y ra
�ings
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Table 17: Module complexi�y ra
�ings
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
137
So�tware Project PlanningProject is di��icult to develop i�Manpower demand is high
When time schedule is short
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
147
So�tware Project Planning0.39 φ
c Technology �actor
Hardware constraints
Experience Complexity
Programming environment
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 �
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
� � � �
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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”.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
207
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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)
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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)
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
84
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
85
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
86
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
87
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
88
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
89
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
90
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
91
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
92
So�tware DesignSo�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
99
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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”.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yoges Sing
, Copyrig
t © New Ag
e International Publisers, 2007
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).
Software Engineering (3rd ed.), By K.K Aggarwal & Yoges Sing
, Copyrig
t © New Ag
e International Publisers, 2007
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
e International Publisers, 2007
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
e International Publisers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yoges Sing
, Copyrig
t ©
ew Ag
e International Publisers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yoges Sing
, Copyrig
t ©
ew Ag
e International Publisers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yoges Sing
, Copyrig
t ©
ew Ag
e International Publisers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yoges Sing
, Copyrig
t ©
ew Ag
e International Publisers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yoges Sing
, Copyrig
t ©
ew Ag
e International Publisers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yoges Sing
, Copyrig
t ©
ew Ag
e International Publisers, 2007
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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200725
Software MetricsSo�ution The �ist of operators and operands is given in tab�e 2.Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200726
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
e International Pu�lis
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
31
Software Metrics
Ta�le 3
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
32
Software Metrics
Ta�le 3
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
34
Software MetricsSolution List of operators and operands are given in Ta
�le 4.
Ta�le 4
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
35
Software Metrics
Ta�le 5
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
40
Software Metrics
Fig.2: Payday programSoftware
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
43
Software Metrics
Fig.6: Program payday wit operands in
�rackets
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
45
Software Metrics
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
cont… 46
Software Metrics
Fig.6: Bu��
le sort programSoftware
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
cont…
49
Software MetricsLine17 18 19 20 21 22 23 24 25 26 27 28 29
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
�ingh, Copyright © New Ag
e International Publishers, 2007
�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
e International Publishers, 2007
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
�ingh, Copyright © New Ag
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
57
Software Metrics
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
58
Software Metrics
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
59
Software Metrics
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
cont… 63
Software MetricsLine27 28 29 30 31 32 33 34 35 36 37 38 39
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
e International Publishers, 2007
cont… 64
Software MetricsLine40 41 42 43 44 45 46 47 48 49 50 51 52
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 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
e International Publishers, 2007
cont… 65
Software MetricsLine53 54 55 56 57 58 59 60 61 62
Live Variableslow, a, item, hi
h, mid low, 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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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?
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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?
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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 ?
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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?
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
106
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
2
Software Relia�ility
Fig. 7.1: Bat tu
� curve of
ardware relia
�ility.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
3
Software Relia�ility
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)
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
4
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
5
Software Relia�ility
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”.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
6
Software Relia�ility
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”.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
7
Software Relia�ility
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
8
Software Relia�ility
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
9
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
10
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
11
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
12
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
Software Relia�ility
Fig. 7.3: Mean Value & failure intensity functions.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
16
Software Relia�ility
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
17
Software Relia�ility
Fig. 7.4: Input Space
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
18
Software Relia�ility
Fig. 7.5: Portion of operational profileSoftware
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
19
Software Relia�ility
Fig. 7.6: Operational profileSoftware
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
20
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
21
Software Relia�ility
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
22
Software Relia�ility
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
23
Software Relia�ility
Software QualityDifferent people understand different meanings of quality like:
conformance to requirements fitness for te purpose level of satisfaction
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
24
Software Relia�ility
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
25
Software Relia�ility
Fig 7.8: Software quality attri�utes
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
26
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
27
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
28
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
29
Software Relia�ility
McCall Software Quality Model
Fig 7.9: Software quality factorsSoftware
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
30
Software Relia�ility
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
31
Software Relia�ility
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
32
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
33
Software Relia�ility
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)
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
34
Quality criteria
Fig 7.10: McCall’s quality modelSoftware
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
35
Software Relia�ility
Ta�le 7.5(a): Relation
�etween quality factors and quality criteria
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
36
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
Software Relia�ility
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.
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
38
Software Relia�ility
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
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
39
Software Relia�ility
Boem Software Quality Model
Fig.7.11: Te Boe
m software quality model
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
40
Software Relia�ility
ISO 9126Functionality Relia
�ility Usa
�ility
�fficiency Maintaina
�ility Porta
�ility
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
41
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
• Maturity
42
Software Relia�ility
• 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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
Software Relia�ility
• 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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
44
Software Relia�ility
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
Software �ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
45
Software Relia�ility
Fig.7.12: ISO 9126 quality modelSoftware
�ngineering (3rd ed.), By K.K Aggarwal & Yoges
Sing
, Copyrig
t © New Ag
e International Pu�lis
ers, 2007
46
Software Relia�ility
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
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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)
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
49
Software Relia�ility
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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 2007
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
Software Relia�ility
(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
Software Relia�ility
� − λ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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200757
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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200758
Software Re�iabi�ityLogarithmic Poisson Execution Time Mode� Fai�ure Intensityλ ( µ ) = λ0 exp(−θµ )
Fig.7.18: Relationship �etween
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
59
Software Relia�ility
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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200761
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
Software Relia�ility
(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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
64
Sof�ware Reliabili
�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
�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
65
Sof�ware Reliabili
�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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200766
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
Software Relia�ility
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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
Software Relia�ility
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 �
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
70
Software Relia�ility
(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
Software Relia�ility
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
Software Relia�ility
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
Software Relia�ility
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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200775
Software Re�iabi�ityFig.7.20: Instantaneous ca�endar time to execution time ratioSoftware Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200776
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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200778
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
79
Sof�ware Reliabili
�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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200781
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
Software Relia�ility
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
83
Sof�ware Reliabili
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
84
Software Relia�ility
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
85
Sof�ware Reliabili
�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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
86
Sof�ware Reliabili
�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 Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200788
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
So�tware Reliability�ig.7.22: Relation between t & λSoftware Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 200790
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
Software Relia�ility
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
Software Relia�ility
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
Software Relia�ility
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
Software Relia�ility
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
Software Relia�ility
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:
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
97
Software Relia�ility
The key process areas at level 3 address �oth project and organizational issues,
as summarized �elow:
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
98
Software Relia�ility
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
99
Software Relia�ility
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:
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
100
Software Relia�ility
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:
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
101
Software Relia�ility
Common Features
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
102
Software Relia�ility
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
103
Software Relia�ility
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
Software Relia�ility
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
Software Relia�ility
15. Handling, storage, packaging and delivery 16. Quality records 17. Internal �
uality audits 18. Training 19. Servicing 20. Statistical techni�ues
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
106
Software Relia�ility
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”.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwa� & Yogesh Singh, Copyright © New Age Internationa� Pub�ishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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?
So�tware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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.
Sof�ware Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyrigh
� © New Ag
e In�erna
�ional Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
126
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
1
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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 Real Roots Real Roots 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
e International Publishers, 2007
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
inary Real Roots Real Roots Ima
in
ary Ima inary Ima
inary Real Roots Real Roots Ima
inary
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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 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
e International Publishers, 2007
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
e International Publishers, 2007
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 Isosceles Not a trian
le Not a trian
le Not a tri
an le Not a trian
le Isosceles 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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
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
e International Publishers, 2007
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
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
e International Publishers, 2007
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
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
105
Software Testin
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
106
Software Testin
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
107
Software Testin
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
108
Software Testin
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
109
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
118
Software Testin
Cont….Software En
ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
119
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
125
Software Testin
Software En ineerin
(3rd ed.), By K.K A
arwal & Yo
esh Sin
h, Copyri
ht © New A
e International Publishers, 2007
126
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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
e International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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 )
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
e International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
142
Software TestingExam
�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:
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
144
Software TestingExam
�le 8.18
Consider the classification of triangle �roblem given in exam
�le 8.14. Find the
cyclomatic com�lexity.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
147
Software Testing
Fig. 24 (b): Flow gra�h and gra
�h matrices
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
148
Software Testing
Fig. 24 (c): Flow gra�h and gra
�h matrices
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
149
Software Testing
Fig. 25 : Connection matrix of flow gra�h shown in Fig. 24 (c)
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
150
Software Testing
The square matrix re�resent that there are two
�ath ab and cd from node 1 to nod
e 2.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
151
Software TestingExam
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
153
Software Testing
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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
e International Publishers, 2007
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).
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
158
Software TestingExam
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
161
Software TestingVariablec d
Path (beginning, end) nodes
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
Software TestingExam
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
164
Software TestingSte
� IV: The du-
�aths are identified and are named by their beginning and ending
nodes using Fig. 20 (a).Variablea
Path (beginning, end) nodes
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
165
Software TestingVariablec
Path (beginning, end) nodes
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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 …….)
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Co�yright © New Ag
e International Publishers, 2007
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
169
Software TestingLevels of TestingThere are 3 levels of testing: i. ii. iii. Unit Testing Integration Testing System Testing
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
172
Software Testing
Fig. 29 : Scaffolding re�uired testing a program unit (module)
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
Software TestingInduction approachLocate the pertinent data Organize the data Devise a hypothesis Prove the hypothesis
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
182
Software Testing
Fig. 32 : The inductive de�ugging process
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
184
Software Testing
Fig. 33 : The inductive de�ugging process
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
188
Multiple Choice QuestionsNote: Choose most appropriate answer of the following
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
203
Exercises8.16 Consider a program given
�elow for the selection of the largest of num
�ers
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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:
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
212
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
8
Software MaintenancePotential Solutions to Maintenance Pro
�lems
Budget and effort reallocation Complete replacement of the system Maintenance of existing system
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
9
Software MaintenanceThe Maintenance Process
Fig. 2: The software maintenance process
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
13
Software MaintenanceIterative Enhancement ModelAnalysis Characterization of proposed modifications Redesign and implementation
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
14
Software MaintenanceAnalyze existing system
Redesign current version and implementation
Characterize proposed modifications
Fig. 4: The three stage cycle of iterative enhancement
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
18
Software MaintenanceManagement decisions
Proposed changes Evaluation Results
Approved changes Change implementation New version of software
Fig. 6: Boehm’s model
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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)
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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 ?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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).
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
44
Software Maintenance
Fig. 11: Levels of a�straction
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Maintenance
Fig. 13: Restructuring a program
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
57
Software Maintenance
Fig. 14: Change re�uest form
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Pu
�lishers, 2007
63
Multiple Choice QuestionsNote: Choose most appropriate answer of the following
�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
Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu�l
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
Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu�l
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
Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu�l
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?
Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu�l
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.
Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu�l
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.
Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Pu�l
ishers
75