Presentation is loading. Please wait.

Presentation is loading. Please wait.

EMBEDDED SOFTWARE 1 (COMPUTER ON CHIP) ATMEL AT80S51 PC12.

Similar presentations


Presentation on theme: "EMBEDDED SOFTWARE 1 (COMPUTER ON CHIP) ATMEL AT80S51 PC12."— Presentation transcript:

1 EMBEDDED SOFTWARE 1 (COMPUTER ON CHIP) ATMEL AT80S51 PC12

2 EMBEDDED SOFTWARE ORG 00H MainLoop: SetBP1.2 ACallDelay ClrP1.2 ACallDelay SJMP MainLoop ; Delay 400Machine Cycles Delay: mov R1, #200 Again: DJNZ R1, Again RETEND 2 COMPUTER ON CHIP Port 1 Port 0 Port 2 Port 3 Time

3 What is a µc? What is a µc? µC is a Computer on chip µC is a Computer on chip 3

4 What is a µc? What is a µc? µC is a Computer on chip µC is a Computer on chip 4

5 COMPUTER SYSTEM 5  Computer System comprises of:- Central Processing Unit - for processingCentral Processing Unit - for processing Keyboard, Mouse - for inputsKeyboard, Mouse - for inputs Monitor, Printer - for outputsMonitor, Printer - for outputs

6 Let us Assemble this Computer 6 KeyboardMonitorCPU KeyboardMonitorCPU

7 7 KeyboardMonitorCPU Keyboard Monitor CPU Control Sensor

8 COMPONENTS ON THE CPU 8 1. Motherboard 2. Microprocessor 3. Memory. ROM ROM RAM RAM 4. Ports. Input ports Input ports Output Ports Output Ports 5. Drives: FDD, HDD, CDR

9 COMPONENTS ON THE CPU 9 Motherboard Motherboard Microprocessor Microprocessor Memory. Memory.  ROM  RAM Ports. Ports.  Input ports  Output Ports Drives: FDD, HDD, Drives: FDD, HDD, CDR CDR Yes Yes On MB On MB Large512MB Ports. Ports. On MB On Ports On Ports No No On Chip On Chip 2,4,..KB 128,.. Byte Ports. Ports. On Chip No drive No drive

10 APPLICATIONS OF SOFTWARE continued... 10

11 4. PRODUCT LINE SOFTWARE 1.Inventory control products. 2.Word processing 3.Spread sheets 4.Computer graphics 5.Multimedia 6.Entertainment 7.Database management 8.Personal and business financial applications. 11

12 5. WEB APPLICATIONS Simple:-Simple:- –Little more than a set of linked hypertext files that present information using text and limited graphics. For E-commerce( Buying and selling ) and B2B (Business to Business)For E-commerce( Buying and selling ) and B2B (Business to Business) –Standalone features, computing functions and content to end user –Integrated with corporate (being a corporation, having a legal existence) databases and business applications. 12

13 6. ARTIFICIAL INTELLIGENCE AI (Artificial Intelligence) software makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis.AI (Artificial Intelligence) software makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Applications in this area include:-Applications in this area include:- –Robotics –Expert systems –Pattern recognition (image and voice) –Artificial neural networks –Theorem proving –Game playing 13

14 ARTIFICIAL NEURAL NETWORKS Traditionally, the term neural network had been used to refer to a network or circuit of biological neurons. The modern usage of the term often refers to artificial neural networks, which are composed of artificial neurons or nodes. Thus the term has two distinct usages: Biological neural networks are made up of real biological neurons that are connected or functionally related in the peripheral nervous system or the central nervous system. In the field of neuroscience, they are often identified as groups of neurons that perform a specific physiological function in laboratory analysis. Artificial neural networks are made up of interconnecting artificial neurons (programming constructs that mimic the properties of biological neurons). Artificial neural networks may either be used to gain an understanding of biological neural networks, or for solving artificial intelligence problems without necessarily creating a model of a real biological system. The real, biological nervous system is highly complex and includes some features that may seem superfluous based on an understanding of artificial networks. 14

15 APPLICATIONS OF SOFTWARE New Challenges:- 1.Ubiquitous Computing. Ubiquitous means found everywhere; omnipresentUbiquitous means found everywhere; omnipresent The rapid growth of wireless networking may soon lead to true distributed computing.The rapid growth of wireless networking may soon lead to true distributed computing. The challenge for SW engineers will be:-The challenge for SW engineers will be:-  to develop systems and application software that will allow small devices, personal computers, and enterprise system  to communicate across vast networks. (Enterprise: an organization created for business ventures, abusiness firm, a company.(Enterprise: an organization created for business ventures, a business firm, a company. Enterprise system: Enterprise system: A system that supports enterprise-wide or cross- functional requirements, rather than a single department or group within the organization) 15

16 DISTRIBUTED COMPUTING Distributed computing deals with:-Distributed computing deals with:- –hardware and software systems containing more than one processing element or storage element, concurrent processes, or multiple programs, running under a loosely or tightly controlled regime. 16

17 DISTRIBUTED COMPUTING In distributed computing:-In distributed computing:- –a program is split up into parts that run simultaneously on multiple computers communicating over a network. Distributed computing is a form of parallel computing, but parallel computing is most commonly used to describe program parts running simultaneously on multiple processors in the same computer.Distributed computing is a form of parallel computing, but parallel computing is most commonly used to describe program parts running simultaneously on multiple processors in the same computer. Both types of processing (i.e. Distributed and Parallel) require dividing a program into parts that can run simultaneously,Both types of processing (i.e. Distributed and Parallel) require dividing a program into parts that can run simultaneously, but distributed programs often must deal with:- –heterogeneous environments, –network links of varying latencies (t ), –network links of varying latencies (the delay before a transfer of data begins following an instruction for its transfer), –and unpredictable failures in the network or the computers. 17

18 APPLICATIONS OF SOFTWARE New Challenges:- 2. Netsourcing. The World Wide Web is rapidly becoming a computing engine as well as content provider.The World Wide Web is rapidly becoming a computing engine as well as content provider. The challenge for SW engineers is to architect simple (e.g. personal financial planning) and sophisticated applications that provide benefit to targeted end-user market worldwide.The challenge for SW engineers is to architect simple (e.g. personal financial planning) and sophisticated applications that provide benefit to targeted end-user market worldwide. (The Web is one of the services available on the Internet. It lets you access millions of pages through a system of links; because it is 'world-wide,' it was originally called the World Wide Web or 18

19 INTERNET Internet.Internet. The Internet is a:-The Internet is a:-  worldwide,  publicly accessible  series of interconnected computer networks  that transmit data by packet switching  using the standard Internet Protocol (IP) The Internet is a:-The Internet is a:-  worldwide communications network  originally developed by the US Department of Defense as a distributed system with no single point of failure. 19

20 TCP/IP Short for “Transmission Control Protocol and Internet Protocol”, two of the core protocols that make the internet work.Short for “Transmission Control Protocol and Internet Protocol”, two of the core protocols that make the internet work. TCP ensures that data is received in the order it is sent,TCP ensures that data is received in the order it is sent, and IP allows computers to identify each other across the internet using IP addresses.and IP allows computers to identify each other across the internet using IP addresses. 20

21 APPLICATIONS OF SOFTWARE New Challenges:- 3. Open Source. A growing trend that results in distribution of source code for system applications (e,g. operating systems, database, and development environment) so that customers can make local modifications.A growing trend that results in distribution of source code for system applications (e,g. operating systems, database, and development environment) so that customers can make local modifications. The challenge for software engineers is to build source code that is self descriptive, but, more importantly to develop techniques that will enable both customers and developers to know what changes have been made and how those changes manifest themselves within the software.The challenge for software engineers is to build source code that is self descriptive, but, more importantly to develop techniques that will enable both customers and developers to know what changes have been made and how those changes manifest themselves within the software. 4. The “New Economy”. The challenge for SW engineers is to build applications that will facilitate:- Mass communicationMass communication Mass product distributionMass product distribution 21

22 APPLICATIONS OF SOFTWARE Further details … 22

23 OTHER APPLICATIONS OF SOFTWARE 1.Real Time S/W 2.Embedded S/W 3.Edutainment S/W 4.Communications S/W 5.Utility S/W 23

24 FOURTH GENERATION TECHNIQUES* 24

25 FOURTH GENERATION TECHNIQUES* 1.The term fourth generation technique (4GT) encompasses a broad array of software tools that have one thing in common :- –each enables the software engineer to specify some characteristics of software at a high level. 2.The tool then automatically generates source code based on the developer's specification. 3.The 4GT paradigm for Software Engineer focuses on the ability to specify software using:- –specialized language forms or –a graphic notation that describes the problems to be solved in terms that the customers can understand. 25

26 FOURTH GENERATION TECHNIQUES… Currently, a software development environment that supports the 4GT paradigm includes some or all of the following tools:-Currently, a software development environment that supports the 4GT paradigm includes some or all of the following tools:- –non procedural languages for:- 1.database query, 2.report generation, 3.data manipulation, 4.screen interaction and definition, 5.code generation ; 6.high-level graphics capability ; 7.spreadsheet capability and 8.automated generation of HTML and similar languages used for web-site creation using advanced software tools. Initially, many of tools noted previously were available only for very specific application domains, but today 4GT environments have been extended to address most software application categories.Initially, many of tools noted previously were available only for very specific application domains, but today 4GT environments have been extended to address most software application categories. 26

27 FOURTH GENERATION TECHNIQUES… Like other paradigms, 4GT begins with a requirements gathering step.Like other paradigms, 4GT begins with a requirements gathering step. Ideally, the customer would describe requirements and these would be directly translated into an operational prototype. But this is unworkable.Ideally, the customer would describe requirements and these would be directly translated into an operational prototype. But this is unworkable. The customer may be unsure of what is required, may be ambiguous in specifying facts that are known, and may be unable or unwilling to specify information in a manner that a 4GT tool can consume.The customer may be unsure of what is required, may be ambiguous in specifying facts that are known, and may be unable or unwilling to specify information in a manner that a 4GT tool can consume. For this reason, the customer/ developer dialog described for other process models remains an essential part of the 4GT approach.For this reason, the customer/ developer dialog described for other process models remains an essential part of the 4GT approach. 27

28 FOURTH GENERATION TECHNIQUES… For small applications, it may be possible to move directly from the requirements gathering step to implementation using a non procedural fourth generation language (4GT) or a model composed of a network of graphical icons.For small applications, it may be possible to move directly from the requirements gathering step to implementation using a non procedural fourth generation language (4GT) or a model composed of a network of graphical icons. However, for larger efforts, it is necessary to develop a design strategy for the system, even if a 4GT is to be used.However, for larger efforts, it is necessary to develop a design strategy for the system, even if a 4GT is to be used. The use of 4GT without design (for large projects) will cause difficulties like:-The use of 4GT without design (for large projects) will cause difficulties like:- –poor quality, –poor maintainability, –poor customer acceptance etc. that have been encountered when developing software using conventional approaches. 28

29 FOURTH GENERATION TECHNIQUES… Implementation using a 4GL enables the software developer to represent desired results in a manner that leads to automatic generation of code to create those results.Implementation using a 4GL enables the software developer to represent desired results in a manner that leads to automatic generation of code to create those results. Obviously, a data structure with relevant information must exist and be readily accessible by the 4GL.Obviously, a data structure with relevant information must exist and be readily accessible by the 4GL. 29

30 FOURTH GENERATION TECHNIQUES… To transform a 4GT implementation into a product, the developer must:-To transform a 4GT implementation into a product, the developer must:- –conduct thorough testing, –develop meaningful documentation, –and perform all other solution integration activities that are required in other software engineering paradigms. In addition, the 4GT developed software must be built in a manner that enables maintenance to be performed expeditiously.In addition, the 4GT developed software must be built in a manner that enables maintenance to be performed expeditiously. 30

31 4GT: ADVANTAGES AND DISADVANTAGES… 1.Like all software engineering paradigms, the 4GT model has advantages and disadvantages. 2.Proponents claim dramatic reduction in software development time and greatly improved productivity for people who built software. 3.Opponents claim that current 4GT tools are not all that much easier to use than programming languages, that the resultant source code produced by such tools is "inefficient", and that the maintainability of large software systems developed using 4GT is open to question. 4.There is some merit in the claims of both sides and it is possible to summarize the current state of 4GT approaches :- 31

32 SUMMARY OF THE CURRENT STATE OF 4GT APPROACHES 1.The use of 4GT is a viable approach for many different application areas. Coupled with computer-aided software engineering tools and code generators, 4GT offers a credible solution to many software problems. 2.Data collected from companies that use 4GT indicate that the time required to produce software is greatly reduced for small and intermediate applications and that the amount of design and analysis for small applications is also reduced. 3.However, the use of 4GT for large software development efforts demands as much or more analysis, design and testing to achieve substantial time savings that result from the elimination of coding. 32

33 FOURTH GENERATION TECHNIQUES MODEL (4 GT MODEL)… Use tools to generate source code based on the specification Use tools to generate source code based on the specification Develop software at faster speed Develop software at faster speed Tools Tools 1.Non Procedural languages for database query 2.Report generation 3.Data manipulation 4.Screen interaction 5.Code generation 6.Graphics capability 7.Spread sheet capability 33

34 OTHER MODELS There are a number of other models for software development like the:-There are a number of other models for software development like the:- –Stepwise Refinement Model, –Industrial and Military Standard Models, –Assembly by Reuse, –Application Generation, –Continuous Transformation Models, –Knowledge-Based Software Automation etc. However, most of these are refinements of the models that we have already discussed, with variations brought in to suit a particular system software or platforms or the nature of the industry.However, most of these are refinements of the models that we have already discussed, with variations brought in to suit a particular system software or platforms or the nature of the industry. 34

35 CONCEPTS OF PROJECT MANAGEMENT* 35

36 CONCEPTS OF PROJECT MANAGEMENT Despite the availability of various engineering paradigms and competent programmers, the years 1960 and early 1970's witnessed a major failure of many large software projects.Despite the availability of various engineering paradigms and competent programmers, the years 1960 and early 1970's witnessed a major failure of many large software projects. The software:-The software:- 1.was delivered late 2.was unreliable 3.cost several times the original estimates and 4.often exhibited poor performance characteristics. These projects failed due to lack of proper project management.These projects failed due to lack of proper project management. 36

37 CONCEPTS OF PROJECT MANAGEMENT… 1.Project Management primary deals with:- –Organizing –planning and –scheduling of software projects. 2.The role of project management is very important because:- –software development is always subject to budget and –schedule constraints. 3.The software project manager's job is to ensure that the software project meets these constraints and delivers software in time. 37

38 CONCEPTS OF PROJECT MANAGEMENT… 1.Software project managers are responsible for:- –planning and scheduling project development. 2.They supervise the work to ensure that it is carried out to the required standards. 3.They regularly monitor progress to check that the development process is on the right track i.e. on time and within budget. 4.Good management does not guarantee project success. However, bad management does lead to project failures. 38

39 CONCEPTS OF PROJECT MANAGEMENT… 5.The Software Project Management becomes all the more important and particularly difficult due to the following reasons:- –S/W Product is Intangible (unable to be touched) –There is no standard process –New S/W projects are not similar to previous ones. 39

40 FOUR P’s IN PROJECT MANAGEMENT Four P’s in Project Management:-Four P’s in Project Management:- 1.People 2.Product 3.Process 4.Project 40

41 CONCEPTS OF PROJECT MANAGEMENT (AS PER ROGER S PRESSMAN) 41

42 CONCEPTS OF ROJECT MANAGEMENT Project management involves:-Project management involves:- –planning, –monitoring, and –control of the  people,  process,  and events that occur as software evolves from a preliminary concept to an operational implementation. that occur as software evolves from a preliminary concept to an operational implementation. 42

43 CONCEPTS OF PROJECT MANAGEMENT Who does it?Who does it? 1.A software engineer manages his day- to-day activities:-1.A software engineer manages his day- to-day activities:-  planning, monitoring, and controlling technical tasks. 2.Project managers plan, monitor, and control the work of a team of software engineers.2.Project managers plan, monitor, and control the work of a team of software engineers. 3.Senior managers coordinate the interface between the business and the software professionals.3.Senior managers coordinate the interface between the business and the software professionals. 43

44 CONCEPTS OF ROJECT MANAGEMENT Why is it important?Why is it important? –Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time. –That’s why software projects need to be managed. 44

45 CONCEPTS OF ROJECT MANAGEMENT What are the steps? Understand the four P’s—Understand the four P’s— –people, –product, –process, –and project. 1.People.People must be organized to perform software work effectively. 2.Product. Communication with the customer must occur so that product scope and requirements are understood. 45

46 CONCEPTS OF ROJECT MANAGEMENT 3.Process.A process must be selected that is appropriate for the people and the product. 4.Project. The project must be planned by estimating effort and calendar time to accomplish work tasks:- – defining work products, – establishing quality checkpoints, and – establishing mechanisms to monitor and control work defined by the plan. 46

47 CONCEPTS OF ROJECT MANAGEMENT What is the work product? A project plan is produced as management activities commence.A project plan is produced as management activities commence. The plan defines:-The plan defines:- –the process and tasks to be conducted, –the people who will do the work, –and the mechanisms for:-  assessing risks,  controlling change, and  evaluating quality. 47

48 CONCEPTS OF ROJECT MANAGEMENT How do I ensure that I’ve done it right?How do I ensure that I’ve done it right? You’re never completely sure that the project plan is right until you’ve delivered a high- quality product on time and within budget.You’re never completely sure that the project plan is right until you’ve delivered a high- quality product on time and within budget. However, a project manager does it right when:-However, a project manager does it right when:- –he encourages software people:-  to work together as an effective team,  focusing their attention on:-  customer needs and product quality. 48

49 FOUR P’s IN PROJECT MANAGEMENT 1.People1.People 1.Senior Managers 2.Project Managers 3.Programmers 4.Customers 5.End users 49

50 FOUR P’s IN PROJECT MANAGEMENT… 1.People…1.People… 1.Senior Managers:They define the business issues that have significant influence on the project.1.Senior Managers:They define the business issues that have significant influence on the project. 2.Project Managers:They plan, motivate, organise and control the programmers who do S/W work.2.Project Managers:They plan, motivate, organise and control the programmers who do S/W work. 3.Programmers:They use technical skills to develop a product.3.Programmers:They use technical skills to develop a product. 4.Customers:They are generally heads of the organisations who specify the needs of the organisation for automation.4.Customers:They are generally heads of the organisations who specify the needs of the organisation for automation. 5.End Users:They would be generally clerks, operators etc. who actually use the S/W. Some functions of the S/W are also used by people higher in chain of command.5.End Users:They would be generally clerks, operators etc. who actually use the S/W. Some functions of the S/W are also used by people higher in chain of command. 50

51 FOUR P’s IN PROJECT MANAGEMENT Project Manager.Project Manager. 1.Motivation 2.Organisation 3.Innovation 4.Problem Solving 5.Managerial Capabilities 6.Leadership Skills 7.Influence and Team Building 51

52 FOUR P’s IN PROJECT MANAGEMENT Programmers/The Software Team.Programmers/The Software Team. 1.Democratic or Egoless Team.1.Democratic or Egoless Team. 2.Controlled Centralised or Chief Programmer Team2.Controlled Centralised or Chief Programmer Team 3.Controlled Decentralised Team3.Controlled Decentralised Team 52

53 FOUR P’s IN PROJECT MANAGEMENT 1. Democratic or Egoless Team.1. Democratic or Egoless Team. 53

54 FOUR P’s IN PROJECT MANAGEMENT Programmers/ The Software Team…Programmers/ The Software Team… 2.Controlled Centralised or Chief Programmer Team2.Controlled Centralised or Chief Programmer Team 54

55 FOUR P’s IN PROJECT MANAGEMENT Programmers/The Software Team.Programmers/The Software Team. 3.Controlled Decentralised Team.3.Controlled Decentralised Team. –This structure tries to combine the strengths of democratic and controlled centralised teams. –It has a Project Leader who has a group of senior programmers under him. –Under each senior programmer is a group of junior programmers. 55

56 FOUR P’s IN PROJECT MANAGEMENT Programmers/ The Software Team.Programmers/ The Software Team. 1.Democratic or Egoless Team.1.Democratic or Egoless Team. –Upto 10 programmers –Goals set by consensus –Inputs from every member are taken for major decisions –Group leadership rotates among team members –Not suitable for:- oComplex tasks oTasks with time constraints, Results in inefficiency 56

57 FOUR P’s IN PROJECT MANAGEMENT Programmers/ The Software Team.Programmers/ The Software Team. 2.Controlled Centralised or Chief Programmer Team.2.Controlled Centralised or Chief Programmer Team. –Follows a hierarchy –There is a chief programmer with:-  Backup programmer  Program librarian for maintaining documentation and other communication related work –Reduced inter-personal communication –Suitable for projects with:-  Simple solutions  Strict deadlines –Not suitable for difficult tasks where multiple inputs are useful. 57

58 Programmers/The Software Team.Programmers/The Software Team. 3.Controlled Decentralised Team3.Controlled Decentralised Team 1.Tries to combine the strengths of democratic and controlled centralised teams. 2.Consists of:- –Project leader with senior programmers under him. –Under each senior programmer:- »a group of junior programmers. »This forms a democratic team »Communication among different groups occurs through senior programmers of respective groups. –Senior programmers also communicate with project leader 3.Fewer communication paths than democratic but more than controlled centralised. 4.Best for large projects that are straight forward. 5.Not well suited for simple projects or research projects. 58

59 PROJECT FACTORS FOR PLANNING SOFTWARE TEAM 1.Difficulty of problem to be solved. 2.Size of resultant program(s) in Lines of Code or Function Points. 3.The time that the team will stay together. 4.Degree to which the problem can be modularised. 5.Required quality and reliability of the system to be built. 6.Rigidity of delivery date. 7.Degree of communication required for the project. 59

60 FOUR P’s IN PROJECT MANAGEMENT 2.The Product.2.The Product. –Software scope must be established and bounded at the very beginning. –Problem Decomposition. 60

61 FOUR P’s IN PROJECT MANAGEMENT 3.The Process.3.The Process. –Generic phases that characterise the software process applicable to all S/W:- DefinitionDefinition DevelopmentDevelopment SupportSupport –Select suitable process model from:- Linear/Life cycleLinear/Life cycle PrototypingPrototyping SpiralSpiral 4GT Model4GT Model –Define project plan based on common process framework activities 61

62 FOUR P’s IN PROJECT MANAGEMENT 4.The Project.4.The Project. –What can go wrong? –How to do it right? –Problem Indicators:- 1.Customer’s needs 2.Scope 3.Changes managed poorly 4.Chosen technology changes 5.Business needs change 6.Deadlines are unrealistic 7.Users are resistant 8.Lacking of appropriate skills 62

63 FOUR P’s IN PROJECT MANAGEMENT The Project.The Project. –How to do it right? 1.Start on the right foot 2.Maintain momentum 3.Track progress 4.Keep it simple 5.Conduct a post-mortem analysis 63

64 PROJECT MANAGEMENT ACTIVITIES 1.Measurement and metrics1.Measurement and metrics 2.Management activities2.Management activities 3.Project planning3.Project planning 4.Scheduling4.Scheduling 5.Tracking5.Tracking 6.Risk management6.Risk management These are umbrella activitiesThese are umbrella activities 64

65 ROLE OF METRICS* 65

66 HOW TO CALULATE COST Cost is generally based on:- Cost is generally based on:- – Utility – Quantity – Quality – Effort involved – Degree of difficulty – Ease of use – Aesthetics 66

67 ROLE OF METRICS Metrics: A standard of measurement Metrics: A standard of measurement For example:- For example:- – Metrics for solids:Weight (kg, gm etc) – Metrics for liquids:Litre, ml etc. – Metrics for gases:Cubic meters, cc etc. – Metrics for length:meter, cm etc. 67

68 ROLE OF METRICS… When you can measure what you are speaking about and express it in numbers, you know something about it;When you can measure what you are speaking about and express it in numbers, you know something about it; –but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meagre ( deficient or inferior ) and unsatisfactory kind:-  it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of a science.- Lord Kelvin 68

69 ROLE OF METRICS… What is metrics?What is metrics? Software process and product metrics are quantitative measures ( measure: size or quantity as ascertained or ascertainable by measuring ) that enable software people:-Software process and product metrics are quantitative measures ( measure: size or quantity as ascertained or ascertainable by measuring ) that enable software people:- –to gain insight into the efficacy of the:- software process and thesoftware process and the projects that are conductedprojects that are conducted using the process as a framework.using the process as a framework. 69

70 ROLE OF METRICS… What is metrics? …What is metrics? … Basic quality and productivity data are collected.Basic quality and productivity data are collected. These data are then:-These data are then:- –analyzed, –compared against past averages, and –assessed to determine:-  whether quality and productivity improvements have occurred. Metrics are also used to pinpoint problem areas so that remedies can be developed and the software process can be improved.Metrics are also used to pinpoint problem areas so that remedies can be developed and the software process can be improved. 70

71 ROLE OF METRICS… Who does it?Who does it? Software metrics are:-Software metrics are:- –analyzed and –assessed by software managers.software managers. Measures are often collected by software engineers.Measures are often collected by software engineers. (Meter rod is a measure, Measuring cloth is measurement. In case of Software: size, No. of functions, No. of Inputs, Outputs etc are measures.) (Meter rod is a measure, Measuring cloth is measurement. In case of Software: size, No. of functions, No. of Inputs, Outputs etc are measures.) 71

72 ROLE OF METRICS… Why is it important?Why is it important? If you don’t measure, judgement can be based only on subjective evaluation.If you don’t measure, judgement can be based only on subjective evaluation. With measurement:-With measurement:- – trends (either good or bad) can be spotted, – better estimates can be made, and –true improvement can be accomplished over time. 72

73 ROLE OF METRICS… What are the steps?What are the steps? Begin by defining a limited set of:-Begin by defining a limited set of:- –process, –project, and –product measures that are  easy to collect. –These measures are often normalized (made equal to a particular value) using:- either size- oreither size- or function-oriented metrics.function-oriented metrics. The result is analyzed and compared to past averages for similar projects performed within the organization.The result is analyzed and compared to past averages for similar projects performed within the organization. Trends are assessed and conclusions are generated.Trends are assessed and conclusions are generated. 73

74 ROLE OF METRICS… What is the work product?What is the work product? A set of software metrics that provide insight into theA set of software metrics that provide insight into the –process and –understanding of the project. ( A software metric is a measure of some property of a piece of software or its specifications.( A software metric is a measure of some property of a piece of software or its specifications.) 74

75 ROLE OF METRICS… How do I ensure that I’ve done it right?How do I ensure that I’ve done it right? By applying a consistent, yet simple measurement scheme that is never to be used to assess, reward, or punish individual performance.By applying a consistent, yet simple measurement scheme that is never to be used to assess, reward, or punish individual performance. 75

76 ROLE OF METRICS… The discipline of software engineering uses the concept of measurement, which enables software managers to:-The discipline of software engineering uses the concept of measurement, which enables software managers to:- –determine the cost and effort devoted to project. –assess software quality. –understand and improve the software process. –Predict, plan and control the software projects. 76

77 SOFTWARE MEASUREMENT… Measures, Metrics and Indicators:-Measures, Metrics and Indicators:- –Measure: A measure provides a quantitative indication of the:- ExtentExtent AmountAmount DimensionDimension CapacityorCapacityor SizeSize of some attribute of a product or process. –Measurement: is the act of determining a measure. –Metric: The IEEE Standard Glossary[IEE93] defines Metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute” 77

78 SOFTWARE MEASUREMENT… There are two types of measurement:-There are two types of measurement:- 1.Direct Measurement 2.Indirect Measurement Entities of S/W Measurement. Three basic entities of S/W need to be measured and controlled:-Entities of S/W Measurement. Three basic entities of S/W need to be measured and controlled:- 1.Process 2.Product 3.Project 78

79 MEASUREMENT CRITERIA A successful measurement program should have the following key characteristics:-A successful measurement program should have the following key characteristics:- –Objective and repeatable –Timely –Iterative –Related to information needs 79

80 MEASUREMENT PROCESS Key stages:-Key stages:- –Plan measurement –Perform measurement –Evaluate measurement –Provide Feedback 80

81 SOFTWARE METRICS A software metric is a quantifiable measure that could be used to measure different characteristics of a S/W or S/W development process.A software metric is a quantifiable measure that could be used to measure different characteristics of a S/W or S/W development process. We need metrics to quantify the:-We need metrics to quantify the:- –Development –Operationand –Maintenance of S/W 81

82 CLASSIFICATION OF S/W METRICS 1.S/W Product metrics 2.S/W Process metrics 3.S/W Project metrics 82

83 NEED FOR S/W METRICS S/W metrics are needed to answer the following:-S/W metrics are needed to answer the following:- 1.How long will it take to complete the project? 2.How much will it cost to complete the project? 3.How many persons and other resources would be required? 4.What would be the likely maintenance cost? 5.What and how to test for better quality? 6.When can the S/W be released? 7.How many errors will be discovered before delivering the product? 8.How much effort would be required to make modifications? 83

84 SOME STANDARD PRODUCT METRICS Size Metrics.Size Metrics. –Lines of Code LOC) –Token Metrics –Function Point and Extended Function Point –Bang Metrics Code complexity metrics.Code complexity metrics. –Cyclomatic Complexity –Information flow 84

85 LOC Size Metrics.S/W size estimation is the process of predicting the size of a S/W product.Size Metrics.S/W size estimation is the process of predicting the size of a S/W product. Lines of Code (LOC).Simplest metric for estimating the effort and size of a computer program.Lines of Code (LOC).Simplest metric for estimating the effort and size of a computer program. Advantages.Simple to measure.Advantages.Simple to measure. Disadvantages.Disadvantages. 1.It is programming language dependent. 2.Does not accommodate non-procedural languages. 3.Poor S/W design may lead to excessive and unnecessary lines of code. 85

86 TOKEN METRICS 1.Major drawback of LOC size measure: –It treats all the lines alike. 2.In program there are some lines which are more difficult to code than others. 3.One solution to this drawback may be to count the basic symbols used in a line instead of lines themselves. 4.These basic symbols are called Tokens, which are classified as either operators or operands. 5.For example:while, for, eof etc are all tokens. 86

87 TOKEN METRICS M.H. Halstead, proposed one of the token metric where the size of a program, which consists of the number of unique tokens can be defined in terms of :M.H. Halstead, proposed one of the token metric where the size of a program, which consists of the number of unique tokens can be defined in terms of : N1 = count of unique operators N2 = count of unique operands Length of program in terms of total number of tokens used isLength of program in terms of total number of tokens used is N = N1+N2 –Where N1 = Count of total occurrences of operators N2 = Count of total occurrences of operands 87

88 TOKEN METRICS An operator, is any symbol or keyword in a program that specifies an action.An operator, is any symbol or keyword in a program that specifies an action. Operators consist of:-Operators consist of:- – symbols such as +, -, /, *, – command names such as ‘while’, ‘for’ and – special symbols such as braces, punctuation marks etc. An operand includes variables, constants and labels.An operand includes variables, constants and labels. 88

89 FUNCTION POINT METRICS 89

90 FUNCTION POINT Function Point(FP) was developed by Allan J. Albrecht in mid 1970’s.Function Point(FP) was developed by Allan J. Albrecht in mid 1970’s. It was an attempt to overcome difficulties associated with LOC as a measure of S/W size, and to assist in developing a mechanism to predict effort associated with S/W development.It was an attempt to overcome difficulties associated with LOC as a measure of S/W size, and to assist in developing a mechanism to predict effort associated with S/W development. FP basically is an objective and structured technique to measure S/W size by quantifying its functionality provided to the user based on the requirements and logical design.FP basically is an objective and structured technique to measure S/W size by quantifying its functionality provided to the user based on the requirements and logical design. This technique breaks the system into smaller components so that they can be better understood and analysed.This technique breaks the system into smaller components so that they can be better understood and analysed. 90

91 FUNCTION POINT FP analysis, thus divides the system into five basic components namely:-FP analysis, thus divides the system into five basic components namely:- 1. External Inputs 2. External Outputs 3. Queries 4. Logical Master File ( Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted. Eg StudentMasterTable, FacultyMasterTable etc) 5.Interface File: It is a file or input-output data that is used by another application. These five components under FP analysis are rated as Simple, Average or Complex.These five components under FP analysis are rated as Simple, Average or Complex. 91

92 FUNCTION POINT 92 Type of Component SimpleAverageComplexTotal 1. External Inputs...x3 = … …x4=……x6=…= 2. External Outputs...x4 = … …x5=……x7=…= 3. Queries...x3 = … …x4=……x6=…= 4. Logical Master Files...x7 = … …x10=……x15=…= 5. Interface File...x5 = … …x7=……x10=…= Count Total = Computing Count Total for FP

93 FUNCTION POINT To compute Function Point, the following relationship is used:To compute Function Point, the following relationship is used: FP = (Count Total) x [ x ∑(Fi)] The Fi (i = 1 to 14) are complexity adjustment values based on the response to the following questions:The Fi (i = 1 to 14) are complexity adjustment values based on the response to the following questions: 93

94 Weightage Each of the following questions is answered using a scale that ranges from Each of the following questions is answered using a scale that ranges from – 0 (not important or applicable) to – 5 (absolutely essential). 94

95 FUNCTION POINT 1. Does the system require reliable backup and recovery? 2. Are data communications required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilised operational environment? 6. Does the system require on-line data entry? 7. Does the on-line data entry require the input transcation to be built over multiple screens or operations? 95

96 FUNCTION POINT 8.Are the master files updated on-line? 9.Are the inputs, outputs, files or queries 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 organisations? 14.Is the application designed to facilitate change and ease of use by the user? 96

97 FUNCTION POINT After the counts for each level of complexity for each type of component are entered, each counter is multiplied by the numerical rating.After the counts for each level of complexity for each type of component are entered, each counter is multiplied by the numerical rating. The rated values on each row are totalled.The rated values on each row are totalled. These totals are then summed down to arrive at the Count Total.These totals are then summed down to arrive at the Count Total. 97

98 FUNCTION POINT Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential). Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential). The constant values in Equation The constant values in Equation FP = (Count Total) x [ x ∑(Fi)] and the weighting factors that are applied to information domain counts are determined empirically. 98

99 FUNCTION POINT Once function points have been calculated, Once function points have been calculated, they are used in a manner analogous to LOC as a way to normalize measures for software productivity, quality, and other attributes: – Errors per FP. – Defects per FP. – $ per FP. – Pages of documentation per FP. – FP per person-month. 99

100 FUNCTION POINT ADVANTAGES Advantages of Function PointAdvantages of Function Point 1.Function points can be used to size software applications accurately. 2.They can be counted by different peopleby different people at different timesat different times to obtain the same measure within a reasonable margin of error.to obtain the same measure within a reasonable margin of error. 3.FP are easily understood by non-technical user. This helps to communicate sizing information to a user or customer. 4.FP can be used to determine whether a tool, a language, an environment is more productive when compared with others. 5.FPs are language independent and can be computed early in a project. 6.Due to these advantages, function points are becoming widely accepted as the standard metric for measuring software size. 100

101 QUALITY METRICS Correctness.Correctness. –Defects per KLOC –Defects are counted over a standard period of time Maintainability.Maintainability. –Ease with which a program can be corrected if an error is encountered –There is no direct method –We measure it indirectly Mean Time To Change (MTTC)Mean Time To Change (MTTC) 101

102 QUALITY METRICS IntegrityIntegrity –This attribute measures a system’s ability to withstand attacks on:- ProgramsPrograms DataData DocumentsDocuments –To measure integrity, two additional attributes must be defined: Threat and Security 102

103 QUALITY METRICS – Threat is the probability (which can be estimated or derived from empirical evidence) that an attack of a specific type will occur within a given time. – Security is the probability (which can be estimated or derived from empirical evidence) that the attack of a specific type will be repelled. – The integrity of a system can then be defined as Integrity = Summation[(1-threat) x (1-security)] (where threat and security are summed over each type of attack. i.e. attack on Programs, Data and Documents) 103

104 QUALITY METRICS Usability.Usability. 1.Physical and or intellectual skill required to learn the system 2.Time required to become moderately efficient 3.The net increase in productivity measured when the system is used by someone who is moderately efficient 4.A subjective assessment of users attitude towards the system. 104

105 PROJECT MANAGEMENT The application of knowledge, skills, tools and techniques to a broad range of activities in order to meet the requirements of a particular project.“The application of knowledge, skills, tools and techniques to a broad range of activities in order to meet the requirements of a particular project.“ The process of directing and controlling a project from start to finish may be further divided into 5 basic phases:The process of directing and controlling a project from start to finish may be further divided into 5 basic phases: 1.Project Conception and Initiation. An idea for a project will be carefully examined to determine whether or not it benefits the organization. During this phase, a decision making team will identify if the project can realistically be completed.An idea for a project will be carefully examined to determine whether or not it benefits the organization. During this phase, a decision making team will identify if the project can realistically be completed. 2. Project Definition and Planning. A project plan, project charter and/or project scope may be put in writing, outlining the work to be performed.A project plan, project charter and/or project scope may be put in writing, outlining the work to be performed. During this phase, a team should prioritize the project, calculate a budget and schedule, and determine what resources are needed.During this phase, a team should prioritize the project, calculate a budget and schedule, and determine what resources are needed. 105

106 PROJECT MANAGEMENT 2. Project definition and planning. A project plan, project charter and/or project scope may be put in writing, outlining the work to be performed. During this phase, a team should prioritize the project, calculate a budget and schedule, and determine what resources are needed.A project plan, project charter and/or project scope may be put in writing, outlining the work to be performed. During this phase, a team should prioritize the project, calculate a budget and schedule, and determine what resources are needed. 3. Project launch or execution Resources' tasks are distributed and teams are informed of responsibilities. This is a good time to bring up important project related information.Resources' tasks are distributed and teams are informed of responsibilities. This is a good time to bring up important project related information. 4. Project performance and control Project managers will compare project status and progress to the actual plan, as resources perform the scheduled work. During this phase, project managers may need to adjust schedules or do what is necessary to keep the project on track.Project managers will compare project status and progress to the actual plan, as resources perform the scheduled work. During this phase, project managers may need to adjust schedules or do what is necessary to keep the project on track. 106

107 PROJECT MANAGEMENT 5. Project close. After project tasks are completed and the client has approved the outcome, an evaluation is necessary to highlight project success and/or learn from project history.After project tasks are completed and the client has approved the outcome, an evaluation is necessary to highlight project success and/or learn from project history. Projects and project management processes vary from industry to industry; however, these are more traditional elements of a project. The overarching goal is typically to offer a product, change a process or to solve a problem in order to benefit the organization.Projects and project management processes vary from industry to industry; however, these are more traditional elements of a project. The overarching goal is typically to offer a product, change a process or to solve a problem in order to benefit the organization. 107

108 CONCEPTS OF PROJECT MANAGEMENT* 108

109 CONCEPTS OF PROJECT MANAGEMENT Despite the availability of various engineering paradigms and competent programmers, the years 1960 and early 1970's witnessed a major failure of many large software projects.Despite the availability of various engineering paradigms and competent programmers, the years 1960 and early 1970's witnessed a major failure of many large software projects. The software:-The software:- 1.was delivered late 2.was unreliable 3.cost several times the original estimates and 4.often exhibited poor performance characteristics. These projects failed due to lack of proper project management.These projects failed due to lack of proper project management. 109

110 CONCEPTS OF PROJECT MANAGEMENT… 1.Project Management primary deals with:- –Organizing –planning and –scheduling of software projects. 2.The role of project management is very important because:- –software development is always subject to budget and –schedule constraints. 3.The software project manager's job is to ensure that the software project meets these constraints and delivers software in time. 110

111 CONCEPTS OF PROJECT MANAGEMENT… 1.Software project managers are responsible for:- –planning and scheduling project development. 2.They supervise the work to ensure that it is carried out to the required standards. 3.They regularly monitor progress to check that the development process is on the right track i.e. on time and within budget. 4.Good management does not guarantee project success. However, bad management does lead to project failures. 111

112 CONCEPTS OF PROJECT MANAGEMENT… 5.The Software Project Management becomes all the more important and particularly difficult due to the following reasons:- –S/W Product is Intangible (unable to be touched) –There is no standard process –New S/W projects are not similar to previous ones. 112

113 Four P’s in Project Management:-Four P’s in Project Management:- 1.People 2.Product 3.Process 4.Project FOUR P’s IN PROJECT MANAGEMENT 113

114 114

115 CONCEPTS OF PROJECT MANAGEMENT (AS PER ROGER S PRESSMAN) 115

116 Project management involves:-Project management involves:- –planning, –monitoring, and –control of the  people,  process,  and events that occur as software evolves from a preliminary concept to an operational implementation. that occur as software evolves from a preliminary concept to an operational implementation. CONCEPTS OF ROJECT MANAGEMENT 116

117 Who does it? 1.A software engineer manages his day-to- day activities:-  planning, monitoring, and controlling technical tasks. 2.Project managers plan, monitor, and control the work of a team of software engineers. 3.Senior managers coordinate the interface between the business and the software professionals. CONCEPTS OF PROJECT MANAGEMENT 117

118 Why is it important?Why is it important? –Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time. –That’s why software projects need to be managed. CONCEPTS OF ROJECT MANAGEMENT 118

119 CONCEPTS OF ROJECT MANAGEMENT What are the steps? Understand the four P’s—Understand the four P’s— –people, –product, –process, –and project. 1.People.People must be organized to perform software work effectively. 2.Product. Communication with the customer must occur so that product scope and requirements are understood. 119

120 CONCEPTS OF ROJECT MANAGEMENT 3.Process.A process must be selected that is appropriate for the people and the product. 4.Project. The project must be planned by estimating effort and calendar time to accomplish work tasks:- – defining work products, – establishing quality checkpoints, and – establishing mechanisms to monitor and control work defined by the plan. 120

121 CONCEPTS OF ROJECT MANAGEMENT What is the work product? A project plan is produced as management activities commence.A project plan is produced as management activities commence. The plan defines:-The plan defines:- –the process and tasks to be conducted, –the people who will do the work, –and the mechanisms for:-  assessing risks,  controlling change, and  evaluating quality. 121

122 How do I ensure that I’ve done it right? You’re never completely sure that the project plan is right until you’ve delivered a high- quality product on time and within budget.You’re never completely sure that the project plan is right until you’ve delivered a high- quality product on time and within budget. However, a project manager does it right when:-However, a project manager does it right when:- –he encourages software people:-  to work together as an effective team,  focusing their attention on:-  customer needs and product quality. CONCEPTS OF ROJECT MANAGEMENT 122

123 1.People 1.Senior Managers 2.Project Managers 3.Programmers 4.Customers 5.End users FOUR P’s IN PROJECT MANAGEMENT 123

124 1.People… 1.Senior Managers:They define the business issues that have significant influence on the project. 2.Project Managers:They plan, motivate, organise and control the programmers who do S/W work. 3.Programmers:They use technical skills to develop a product. 4.Customers:They are generally heads of the organisations who specify the needs of the organisation for automation. 5.End Users:They would be generally clerks, operators etc. who actually use the S/W. Some functions of the S/W are also used by people higher in chain of command. FOUR P’s IN PROJECT MANAGEMENT… 124

125 Project Manager.Project Manager. 1.Motivation 2.Organisation 3.Innovation 4.Problem Solving 5.Managerial Capabilities 6.Leadership Skills 7.Influence and Team Building FOUR P’s IN PROJECT MANAGEMENT 125

126 Programmers/The Software Team.Programmers/The Software Team. 1.Democratic or Egoless Team. 2.Controlled Centralised or Chief Programmer Team 3.Controlled Decentralised Team FOUR P’s IN PROJECT MANAGEMENT 126

127 1. Democratic or Egoless Team. FOUR P’s IN PROJECT MANAGEMENT 127

128 Programmers/ The Software Team…Programmers/ The Software Team… 2.Controlled Centralised or Chief Programmer Team FOUR P’s IN PROJECT MANAGEMENT 128

129 SOFTWARE PROJECT MANAGEMENT* In this part of Software Engineering you’ll learn the management techniques required toIn this part of Software Engineering you’ll learn the management techniques required to plan,plan, organize,organize, monitor, andmonitor, and control software projects.control software projects. 129

130 SOFTWARE PROJECT MANAGEMENT These questions are addressed:These questions are addressed: How must people, process, and problem be managed during a software project?How must people, process, and problem be managed during a software project? How can software metrics be used to manage a software project and the software process?How can software metrics be used to manage a software project and the software process? How does a software team generate reliable estimates of effort, cost, and project duration?How does a software team generate reliable estimates of effort, cost, and project duration? What techniques can be used to assess the risks that can have an impact on project success?What techniques can be used to assess the risks that can have an impact on project success? How does a software project manager select a set of software engineering work tasks?How does a software project manager select a set of software engineering work tasks? How is a project schedule created?How is a project schedule created? Why are maintenance and reengineering so important for both software engineering managers and practitioners?Why are maintenance and reengineering so important for both software engineering managers and practitioners? Once these questions are answered, you’ll be better prepared to manage software projects in a way that will lead to timely delivery of a high-quality product.Once these questions are answered, you’ll be better prepared to manage software projects in a way that will lead to timely delivery of a high-quality product. 130

131 SOFTWARE PROJECT MANAGEMENT What is it? Project management involves theProject management involves the planning,planning, monitoring, andmonitoring, and control of thecontrol of the people,people, process, andprocess, and eventsevents that occur as software evolves from a preliminary concept to full operational deployment. 131

132 SOFTWARE PROJECT MANAGEMENT Who does it? Everyone “manages” to some extent, but the scope of management activities varies among people involved in a software project.Everyone “manages” to some extent, but the scope of management activities varies among people involved in a software project. A software engineer manages day-to-day activities,A software engineer manages day-to-day activities, planning,planning, monitoring, andmonitoring, and controllingcontrolling technical tasks. Project managers plan, monitor, and control the work of a team of software engineers.Project managers plan, monitor, and control the work of a team of software engineers. Senior managers coordinate the interface between the business and software professionals.Senior managers coordinate the interface between the business and software professionals. 132

133 SOFTWARE PROJECT MANAGEMENT Why is it important? Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time.Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time. That’s why software projects need to be managed.That’s why software projects need to be managed. What are the steps? Understand the four P’s —Understand the four P’s — people, product, process, and project.people, product, process, and project. People must be organized to perform software work effectively.People must be organized to perform software work effectively. Communication with the customer and other stakeholders must occur so that product scope and requirements are understood.Communication with the customer and other stakeholders must occur so that product scope and requirements are understood. A process that is appropriate for the people and the product should be selected.A process that is appropriate for the people and the product should be selected. The project must be planned by estimating effort and calendar time to accomplish work tasks: defining work products, establishing quality checkpoints, and identifying mechanisms to monitor and control work defined by the plan.The project must be planned by estimating effort and calendar time to accomplish work tasks: defining work products, establishing quality checkpoints, and identifying mechanisms to monitor and control work defined by the plan. 133

134 SOFTWARE PROJECT MANAGEMENT What is the work product? A project plan is produced as management activities commence. The plan defines the process and tasks to be conducted, the people who will do the work, and the mechanisms for assessing risks, controlling change, and evaluating quality.A project plan is produced as management activities commence. The plan defines the process and tasks to be conducted, the people who will do the work, and the mechanisms for assessing risks, controlling change, and evaluating quality. How do I ensure that I’ve done it right? You’re never completely sure that the project plan is right until you’ve delivered a high-quality product on time and within budget.You’re never completely sure that the project plan is right until you’ve delivered a high-quality product on time and within budget. However, a project manager does it right when he encourages software people to work together as an effective team, focusing their attention on customer needs and product quality.However, a project manager does it right when he encourages software people to work together as an effective team, focusing their attention on customer needs and product quality. 134

135 THE MANAGEMENT SPECTRUM* 135 Spectrum means:Spectrum means: –A broad sequence or range of related qualities, ideas, or activities.

136 THE MANAGEMENT SPECTRUM Effective software project management focuses on the four P’s:Effective software project management focuses on the four P’s: people,people, product,product, process, andprocess, and project.project. The order is not arbitrary.The order is not arbitrary. The manager who forgets that software engineering work is an intensely human endeavor will never have success in project management.The manager who forgets that software engineering work is an intensely human endeavor will never have success in project management. A manager who fails to encourage comprehensive stakeholder communication early in the evolution of a product risks building an elegant solution for the wrong problem.A manager who fails to encourage comprehensive stakeholder communication early in the evolution of a product risks building an elegant solution for the wrong problem. 136

137 THE MANAGEMENT SPECTRUM The manager who pays little attention to the process runs the risk of inserting competent technical methods and tools into a vacuum.The manager who pays little attention to the process runs the risk of inserting competent technical methods and tools into a vacuum. The manager who embarks ( Embark: Go on board a ship, aircraft, or other vehicle ) without a solid project plan jeopardizes the success of the project.The manager who embarks ( Embark: Go on board a ship, aircraft, or other vehicle ) without a solid project plan jeopardizes the success of the project. 137

138 THE MANAGEMENT SPECTRUM The People The cultivation of motivated, highly skilled software people has been discussed since the 1960s.The cultivation of motivated, highly skilled software people has been discussed since the 1960s. In fact, the “people factor” is so important that the Software Engineering Institute has developed a People Capability Maturity Model (People-CMM), in recognition of the fact that “every organization needs to continually improve its ability toIn fact, the “people factor” is so important that the Software Engineering Institute has developed a People Capability Maturity Model (People-CMM), in recognition of the fact that “every organization needs to continually improve its ability to attract,attract, develop,develop, motivate,motivate, organize, andorganize, and retainretain the workforce needed to accomplish its strategic business objectives”. 138

139 THE MANAGEMENT SPECTRUM The People… The people capability maturity model defines the following key practice areas for software people:The people capability maturity model defines the following key practice areas for software people: staffing,staffing, communication and coordination,communication and coordination, work environment,work environment, performance management,performance management, training,training, compensation,compensation, competency analysis andcompetency analysis and development, career development, workgroup development, team/culture development, and others.development, career development, workgroup development, team/culture development, and others. 139

140 THE MANAGEMENT SPECTRUM The People… Organizations that achieve high levels of People-CMM maturity have a higher likelihood of implementing effective software project management practices.Organizations that achieve high levels of People-CMM maturity have a higher likelihood of implementing effective software project management practices. The People-CMM is a companion to the Software Capability Maturity Model–Integration (Chapter 30) that guides organizations in the creation of a mature software process. Issues associated with people management and structure for softwareThe People-CMM is a companion to the Software Capability Maturity Model–Integration (Chapter 30) that guides organizations in the creation of a mature software process. Issues associated with people management and structure for software projects are considered later in this chapter.projects are considered later in this chapter. 140

141 THE MANAGEMENT SPECTRUM The Product… Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified.Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified. Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress.Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress. As a software developer, you and other stakeholders must meet to define product objectives and scope.As a software developer, you and other stakeholders must meet to define product objectives and scope. In many cases, this activity begins as part of the system engineering or business process engineering and continues as the first step in software requirements engineering. Objectives identify the overall goals for the product (from the stakeholders’ points of view) without considering how these goals will be achieved.In many cases, this activity begins as part of the system engineering or business process engineering and continues as the first step in software requirements engineering. Objectives identify the overall goals for the product (from the stakeholders’ points of view) without considering how these goals will be achieved. 141

142 THE MANAGEMENT SPECTRUM The Product… Scope identifies the primary data, functions, and behaviors that characterize the product, and more important, attempts to bound these characteristics in a quantitative manner.Scope identifies the primary data, functions, and behaviors that characterize the product, and more important, attempts to bound these characteristics in a quantitative manner. Once the product objectives and scope are understood, alternative solutions are considered.Once the product objectives and scope are understood, alternative solutions are considered. Although very little detail is discussed, the alternatives enable managers and practitioners to select a “best” approach, given the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability, technical interfaces, and myriad other factors.Although very little detail is discussed, the alternatives enable managers and practitioners to select a “best” approach, given the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability, technical interfaces, and myriad other factors. 142

143 THE MANAGEMENT SPECTRUM The Process A software process provides the framework from which a comprehensive plan for software development can be established.A software process provides the framework from which a comprehensive plan for software development can be established. A small number of framework activities are applicable to all software projects, regardless of their size or complexity.A small number of framework activities are applicable to all software projects, regardless of their size or complexity. A number of different task sets — tasks, milestones, work products, and quality assurance points — enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team.A number of different task sets — tasks, milestones, work products, and quality assurance points — enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. Finally, umbrella activities — such as software quality assurance, software configuration management, and measurement — overlay the process model.Finally, umbrella activities — such as software quality assurance, software configuration management, and measurement — overlay the process model. Umbrella activities are independent of any one framework activity and occur throughout the process.Umbrella activities are independent of any one framework activity and occur throughout the process. 143

144 THE MANAGEMENT SPECTRUM The Process We conduct planned and controlled software projects for one primary reason - it is the only known way to manage complexity. And yet, software teams still struggle.We conduct planned and controlled software projects for one primary reason - it is the only known way to manage complexity. And yet, software teams still struggle. In a study of 250 large software projects between 1998 and 2004, Capers Jones found that “about 25 were deemed successful in that they achieved their schedule, cost, and quality objectives.In a study of 250 large software projects between 1998 and 2004, Capers Jones found that “about 25 were deemed successful in that they achieved their schedule, cost, and quality objectives. About 50 had delays or overruns below 35 percent, while about 175 experienced major delays and overruns, or were terminated without completion.”About 50 had delays or overruns below 35 percent, while about 175 experienced major delays and overruns, or were terminated without completion.” Although the success rate for present-day software projects may have improved somewhat, our project failure rate remains much higher than it should be.Although the success rate for present-day software projects may have improved somewhat, our project failure rate remains much higher than it should be. 144

145 THE MANAGEMENT SPECTRUM The Process… To avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring, and controlling the project.To avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring, and controlling the project. 145

146 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS* 146

147 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS Software Project Planning Software project management begins with a set of activities that are collectively called project planning.Software project management begins with a set of activities that are collectively called project planning. Before the project can begin, the software team should estimate the work to be done, the resources that will be required, and the time that will elapse from start to finish.Before the project can begin, the software team should estimate the work to be done, the resources that will be required, and the time that will elapse from start to finish. Once these activities are accomplished, the software team should establish a project schedule that defines software engineering tasks and milestones, identifies who is responsible for conducting each task, and specifies the intertask dependencies that may have a strong bearing on progress.Once these activities are accomplished, the software team should establish a project schedule that defines software engineering tasks and milestones, identifies who is responsible for conducting each task, and specifies the intertask dependencies that may have a strong bearing on progress. 147

148 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS Software Project Planning… In an excellent guide to “software project survival,” Steve McConnell presents a real-world view of project planning:In an excellent guide to “software project survival,” Steve McConnell presents a real-world view of project planning: Many technical workers would rather do technical work than spend time planning.Many technical workers would rather do technical work than spend time planning. Many technical managers do not have sufficient training in technical management to feel confident that their planning will improve a project’s outcome.Many technical managers do not have sufficient training in technical management to feel confident that their planning will improve a project’s outcome. Since neither party wants to do planning, it often doesn’t get done.Since neither party wants to do planning, it often doesn’t get done. But failure to plan is one of the most critical mistakes a project can make... effective planning is needed to resolve problems upstream [early in the project] at low cost, rather than downstream [late in the project] at high cost.But failure to plan is one of the most critical mistakes a project can make... effective planning is needed to resolve problems upstream [early in the project] at low cost, rather than downstream [late in the project] at high cost. 148

149 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS Software Project Planning… The average project spends 80 percent of its time on rework—fixing mistakes that were made earlier in the project.The average project spends 80 percent of its time on rework—fixing mistakes that were made earlier in the project. McConnell argues that every team can find the time to plan ( and to adapt the plan throughout the project ) simply by taking a small percentage of the time that would have been spent on rework that occurs because planning was not conducted.McConnell argues that every team can find the time to plan ( and to adapt the plan throughout the project ) simply by taking a small percentage of the time that would have been spent on rework that occurs because planning was not conducted. 149

150 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS What is it? A real need for software has been established; stakeholders are onboard, software engineers are ready to start, and the project is about to begin.A real need for software has been established; stakeholders are onboard, software engineers are ready to start, and the project is about to begin. But how do you proceed?But how do you proceed? Software project planning encompasses five major activities —Software project planning encompasses five major activities — 1.estimation, 2.scheduling, 3.risk analysis, 4.quality management planning, and 5.change management planning. 150

151 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS What is it? As of now, we consider only estimation — your attempt to determine how muchAs of now, we consider only estimation — your attempt to determine how much money,money, effort,effort, resources, andresources, and time it will taketime it will take to build a specific software-based system or product. 151

152 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS Who does it? Software project managers — using information solicited from project stakeholders and software metrics data collected from past projects.Software project managers — using information solicited from project stakeholders and software metrics data collected from past projects. Why is it important? Would you build a house without knowing how much you were about to spend, the tasks that you need to perform, and the time line for the work to be conducted?Would you build a house without knowing how much you were about to spend, the tasks that you need to perform, and the time line for the work to be conducted? Of course not, and since most computer-based systems and products cost considerably more to build than a large house, it would seem reasonable to develop an estimate before you start creating the software.Of course not, and since most computer-based systems and products cost considerably more to build than a large house, it would seem reasonable to develop an estimate before you start creating the software. 152

153 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS What are the steps? Estimation begins with a description of the scope of the problem.Estimation begins with a description of the scope of the problem. The problem is then decomposed into a set of smaller problems, and each of these is estimated using historical data and experience as guides.The problem is then decomposed into a set of smaller problems, and each of these is estimated using historical data and experience as guides. Problem complexity and risk are considered before a final estimate is made.Problem complexity and risk are considered before a final estimate is made. 153

154 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS What is the work product? A simple table delineating theA simple table delineating the tasks to be performed,tasks to be performed, the functions to be implemented, andthe functions to be implemented, and the cost, effort, and time involved for each is generated.the cost, effort, and time involved for each is generated. 154

155 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS How do I ensure that I’ve done it right? That’s hard, because you won’t really know until the project has been completed.That’s hard, because you won’t really know until the project has been completed. However,However, if you have experience and follow a systematic approach,if you have experience and follow a systematic approach, generate estimates using solid historical data,generate estimates using solid historical data, create estimation data points using at least two different methods,create estimation data points using at least two different methods, establish a realistic schedule, and continually adapt it as the project moves forward,establish a realistic schedule, and continually adapt it as the project moves forward, you can feel confident that you’ve given it your best shot. 155

156 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS Characteristics of Software Project Planning A project plan can be considered to have five key characteristics that have to be managed:A project plan can be considered to have five key characteristics that have to be managed: 1.Scope. Scope defines what will be covered in a project. 2.Resource. Resource includes what can be used to meet the scope. 3.Time. Specifies what tasks are to be undertaken and when. 4.Quality. Indicates the spread or deviation allowed from a desired standard. 5.Risk. Defines in advance what may happen to drive the plan off course, and what will be done to recover the situation. 156

157 SOFTWARE PROJECT PLANNING AND ITS CHARACTERISTICS Characteristics of Software Project Planning 1.A positive relationship with an active, intelligent client. 2.Strong project management. 3.Clear requirements, well managed. 4.Ruthless change management. 5.Pervasive process focus. 6.Effective controls and communication. 7.Technical leadership and excellence. 8.An honest self analysis of projects. An analysis based on these seven criteria is something that a PM-COE should consider as part of its continuing process improvement. 157

158 FOUR P’s IN PROJECT MANAGEMENT 1.People.1.People. 1.Senior Managers 2.Project Managers 3.Programmers 4.Customers 5.End users 158

159 FOUR P’s IN PROJECT MANAGEMENT… 1.People…1.People… 1.Senior Managers:They define the business issues that have significant influence on the project.1.Senior Managers:They define the business issues that have significant influence on the project. 2.Project Managers:They plan, motivate, organise and control the programmers who do S/W work.2.Project Managers:They plan, motivate, organise and control the programmers who do S/W work. 3.Programmers:They use technical skills to develop a product.3.Programmers:They use technical skills to develop a product. 4.Customers:They are generally heads of the organisations who specify the needs of the organisation for automation.4.Customers:They are generally heads of the organisations who specify the needs of the organisation for automation. 5.End Users:They would be generally clerks, operators etc. who actually use the S/W. Some functions of the S/W are also used by people higher in chain of command.5.End Users:They would be generally clerks, operators etc. who actually use the S/W. Some functions of the S/W are also used by people higher in chain of command. 159

160 FOUR P’s IN PROJECT MANAGEMENT Project Manager.Project Manager. 1.Motivation 2.Organisation 3.Innovation 4.Problem Solving 5.Managerial Capabilities 6.Leadership Skills 7.Influence and Team Building 160

161 FOUR P’s IN PROJECT MANAGEMENT Programmers/The Software Team.Programmers/The Software Team. 1.Democratic or Egoless Team.1.Democratic or Egoless Team. 2.Controlled Centralised or Chief Programmer Team2.Controlled Centralised or Chief Programmer Team 3.Controlled Decentralised Team3.Controlled Decentralised Team 161

162 FOUR P’s IN PROJECT MANAGEMENT 1. Democratic or Egoless Team.1. Democratic or Egoless Team. 162

163 FOUR P’s IN PROJECT MANAGEMENT Programmers/ The Software Team…Programmers/ The Software Team… 2.Controlled Centralised or Chief Programmer Team2.Controlled Centralised or Chief Programmer Team 163

164 FOUR P’s IN PROJECT MANAGEMENT Programmers/The Software Team.Programmers/The Software Team. 3.Controlled Decentralised Team.3.Controlled Decentralised Team. –This structure tries to combine the strengths of democratic and controlled centralised teams. –It has a Project Leader who has a group of senior programmers under him. –Under each senior programmer is a group of junior programmers. 164

165 FOUR P’s IN PROJECT MANAGEMENT Programmers/ The Software Team.Programmers/ The Software Team. 1.Democratic or Egoless Team.1.Democratic or Egoless Team. –Upto 10 programmers –Goals set by consensus –Inputs from every member are taken for major decisions –Group leadership rotates among team members –Not suitable for:- oComplex tasks oTasks with time constraints, Results in inefficiency 165

166 FOUR P’s IN PROJECT MANAGEMENT Programmers/ The Software Team.Programmers/ The Software Team. 2.Controlled Centralised or Chief Programmer Team.2.Controlled Centralised or Chief Programmer Team. –Follows a hierarchy –There is a chief programmer with:-  Backup programmer  Program librarian for maintaining documentation and other communication related work –Reduced inter-personal communication –Suitable for projects with:-  Simple solutions  Strict deadlines –Not suitable for difficult tasks where multiple inputs are useful. 166

167 Programmers/The Software Team.Programmers/The Software Team. 3.Controlled Decentralised Team3.Controlled Decentralised Team 1.Tries to combine the strengths of democratic and controlled centralised teams. 2.Consists of:- –Project leader with senior programmers under him. –Under each senior programmer:- »a group of junior programmers. »This forms a democratic team »Communication among different groups occurs through senior programmers of respective groups. –Senior programmers also communicate with project leader 3.Fewer communication paths than democratic but more than controlled centralised. 4.Best for large projects that are straight forward. 5.Not well suited for simple projects or research projects. 167

168 PROJECT FACTORS FOR PLANNING SOFTWARE TEAM 1.Difficulty of problem to be solved. 2.Size of resultant program(s) in Lines of Code or Function Points. 3.The time that the team will stay together. 4.Degree to which the problem can be modularised. 5.Required quality and reliability of the system to be built. 6.Rigidity of delivery date. 7.Degree of communication required for the project. 168

169 FOUR P’s IN PROJECT MANAGEMENT 2.The Product.2.The Product. –Software scope must be established and bounded at the very beginning. –Problem Decomposition. 169

170 FOUR P’s IN PROJECT MANAGEMENT 3.The Process.3.The Process. –Generic phases that characterise the software process applicable to all S/W:- DefinitionDefinition DevelopmentDevelopment SupportSupport –Select suitable process model from:- Linear/Life cycleLinear/Life cycle PrototypingPrototyping SpiralSpiral 4GT Model4GT Model –Define project plan based on common process framework activities 170

171 FOUR P’s IN PROJECT MANAGEMENT 4.The Project.4.The Project. –What can go wrong? –How to do it right? –Problem Indicators:- 1.Customer’s needs 2.Scope 3.Changes managed poorly 4.Chosen technology changes 5.Business needs change 6.Deadlines are unrealistic 7.Users are resistant 8.Lacking of appropriate skills 171

172 FOUR P’s IN PROJECT MANAGEMENT The Project.The Project. –How to do it right? 1.Start on the right foot 2.Maintain momentum 3.Track progress 4.Keep it simple 5.Conduct a post-mortem analysis 172

173 CONCEPTS OF PROJECT MANAGEMENT 173

174 CONCEPTS OF PROJECT MANAGEMENT Despite the availability of various engineering paradigms and competent programmers, the years 1960 and early 1970's witnessed a major failure of many large software projects.Despite the availability of various engineering paradigms and competent programmers, the years 1960 and early 1970's witnessed a major failure of many large software projects. The software:-The software:- 1.was delivered late 2.was unreliable 3.cost several times the original estimates and 4.often exhibited poor performance characteristics. These projects failed due to lack of proper project management.These projects failed due to lack of proper project management. 174

175 CONCEPTS OF PROJECT MANAGEMENT… 1.Project Management primary deals with:- –Organizing –planning and –scheduling of software projects. 2.The role of project management is very important because:- –software development is always subject to budget and –schedule constraints. 3.The software project manager's job is to ensure that the software project meets these constraints and delivers software in time. 175

176 CONCEPTS OF PROJECT MANAGEMENT… 1.Software project managers are responsible for:- –planning and scheduling project development. 2.They supervise the work to ensure that it is carried out to the required standards. 3.They regularly monitor progress to check that the development process is on the right track i.e. on time and within budget. 4.Good management does not guarantee project success. However, bad management does lead to project failures. 176

177 CONCEPTS OF PROJECT MANAGEMENT… 5.The Software Project Management becomes all the more important and particularly difficult due to the following reasons:- –S/W Product is Intangible (unable to be touched) –There is no standard process –New S/W projects are not similar to previous ones. 177

178 FOUR P’s IN PROJECT MANAGEMENT Four P’s in Project Management:-Four P’s in Project Management:- 1.People 2.Product 3.Process 4.Project 178

179 CONCEPTS OF PROJECT MANAGEMENT (AS PER ROGER S PRESSMAN) 179

180 CONCEPTS OF ROJECT MANAGEMENT Project management involves:-Project management involves:- –planning, –monitoring, and –control of the  people,  process,  and events that occur as software evolves from a preliminary concept to an operational implementation. that occur as software evolves from a preliminary concept to an operational implementation. 180

181 CONCEPTS OF PROJECT MANAGEMENT Who does it?Who does it? 1.A software engineer manages his day- to-day activities:-1.A software engineer manages his day- to-day activities:-  planning, monitoring, and controlling technical tasks. 2.Project managers plan, monitor, and control the work of a team of software engineers.2.Project managers plan, monitor, and control the work of a team of software engineers. 3.Senior managers coordinate the interface between the business and the software professionals.3.Senior managers coordinate the interface between the business and the software professionals. 181

182 CONCEPTS OF ROJECT MANAGEMENT Why is it important?Why is it important? –Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time. –That’s why software projects need to be managed. 182

183 CONCEPTS OF ROJECT MANAGEMENT What are the steps? Understand the four P’s—Understand the four P’s— –people, –product, –process, –and project. 1.People.People must be organized to perform software work effectively. 2.Product. Communication with the customer must occur so that product scope and requirements are understood. 183

184 CONCEPTS OF ROJECT MANAGEMENT 3.Process.A process must be selected that is appropriate for the people and the product. 4.Project. The project must be planned by estimating effort and calendar time to accomplish work tasks:- defining work products,defining work products, establishing quality checkpoints, andestablishing quality checkpoints, and establishing mechanisms to monitor and control work defined by the plan.establishing mechanisms to monitor and control work defined by the plan. 184

185 CONCEPTS OF ROJECT MANAGEMENT What is the work product? A project plan is produced as management activities commence.A project plan is produced as management activities commence. The plan defines:-The plan defines:- –the process and tasks to be conducted, –the people who will do the work, –and the mechanisms for:-  assessing risks,  controlling change, and  evaluating quality. 185

186 CONCEPTS OF ROJECT MANAGEMENT How do I ensure that I’ve done it right?How do I ensure that I’ve done it right? You’re never completely sure that the project plan is right until you’ve delivered a high- quality product on time and within budget.You’re never completely sure that the project plan is right until you’ve delivered a high- quality product on time and within budget. However, a project manager does it right when:-However, a project manager does it right when:- –he encourages software people:-  to work together as an effective team,  focusing their attention on:-  customer needs and product quality. 186

187 PROJECT MANAGEMENT ACTIVITIES 1.Measurement and metrics1.Measurement and metrics 2.Management activities2.Management activities 3.Project planning3.Project planning 4.Scheduling4.Scheduling 5.Tracking5.Tracking 6.Risk management6.Risk management These are umbrella activitiesThese are umbrella activities 187

188 ROLE OF METRICS* 188

189 HOW TO CALULATE COST Cost is generally based on:-Cost is generally based on:- UtilityUtility QuantityQuantity QualityQuality Effort involvedEffort involved Degree of difficultyDegree of difficulty Ease of useEase of use AestheticsAesthetics 189

190 ROLE OF METRICS Metrics: A standard of measurementMetrics: A standard of measurement For example:-For example:- Metrics for solids:Weight (kg, gm etc)Metrics for solids:Weight (kg, gm etc) Metrics for liquids:Litre, ml etc.Metrics for liquids:Litre, ml etc. Metrics for gases:Cubic meters, cc etc.Metrics for gases:Cubic meters, cc etc. Metrics for length:meter, cm etc.Metrics for length:meter, cm etc. 190

191 ROLE OF METRICS… When you can measure what you are speaking about and express it in numbers, you know something about it;When you can measure what you are speaking about and express it in numbers, you know something about it; –but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meagre ( deficient or inferior ) and unsatisfactory kind:-  it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of a science.- Lord Kelvin 191

192 ROLE OF METRICS… What is metrics?What is metrics? Software process and product metrics are quantitative measures ( measure: size or quantity as ascertained or ascertainable by measuring ) that enable software people:-Software process and product metrics are quantitative measures ( measure: size or quantity as ascertained or ascertainable by measuring ) that enable software people:- –to gain insight into the efficacy of the:- software process and thesoftware process and the projects that are conductedprojects that are conducted using the process as a framework.using the process as a framework. 192

193 ROLE OF METRICS… What is metrics? …What is metrics? … Basic quality and productivity data are collected.Basic quality and productivity data are collected. These data are then:-These data are then:- –analyzed, –compared against past averages, and –assessed to determine:-  whether quality and productivity improvements have occurred. Metrics are also used to pinpoint problem areas so that remedies can be developed and the software process can be improved.Metrics are also used to pinpoint problem areas so that remedies can be developed and the software process can be improved. 193

194 ROLE OF METRICS… Who does it?Who does it? Software metrics are:-Software metrics are:- –analyzed and –assessed by software managers.software managers. Measures are often collected by software engineers.Measures are often collected by software engineers. (Meter rod is a measure, Measuring cloth is measurement. In case of Software: size, No. of functions, No. of Inputs, Outputs etc are measures.) (Meter rod is a measure, Measuring cloth is measurement. In case of Software: size, No. of functions, No. of Inputs, Outputs etc are measures.) 194

195 ROLE OF METRICS… Why is it important?Why is it important? If you don’t measure, judgement can be based only on subjective evaluation.If you don’t measure, judgement can be based only on subjective evaluation. With measurement:-With measurement:- – trends (either good or bad) can be spotted, – better estimates can be made, and –true improvement can be accomplished over time. 195

196 ROLE OF METRICS… What are the steps?What are the steps? Begin by defining a limited set of:-Begin by defining a limited set of:- –process, –project, and –product measures that are  easy to collect. –These measures are often normalized (made equal to a particular value) using:- either size- oreither size- or function-oriented metrics.function-oriented metrics. The result is analyzed and compared to past averages for similar projects performed within the organization.The result is analyzed and compared to past averages for similar projects performed within the organization. Trends are assessed and conclusions are generated.Trends are assessed and conclusions are generated. 196

197 ROLE OF METRICS… What is the work product?What is the work product? A set of software metrics that provide insight into theA set of software metrics that provide insight into the –process and –understanding of the project. ( A software metric is a measure of some property of a piece of software or its specifications.( A software metric is a measure of some property of a piece of software or its specifications.) 197

198 ROLE OF METRICS… How do I ensure that I’ve done it right?How do I ensure that I’ve done it right? By applying a consistent, yet simple measurement scheme that is never to be used to assess, reward, or punish individual performance.By applying a consistent, yet simple measurement scheme that is never to be used to assess, reward, or punish individual performance. 198

199 ROLE OF METRICS… The discipline of software engineering uses the concept of measurement, which enables software managers to:-The discipline of software engineering uses the concept of measurement, which enables software managers to:- –determine the cost and effort devoted to project. –assess software quality. –understand and improve the software process. –Predict, plan and control the software projects. 199

200 SOFTWARE MEASUREMENT… Measures, Metrics and Indicators:-Measures, Metrics and Indicators:- –Measure: A measure provides a quantitative indication of the:- ExtentExtent AmountAmount DimensionDimension CapacityorCapacityor SizeSize of some attribute of a product or process. –Measurement: is the act of determining a measure. –Metric: The IEEE Standard Glossary[IEE93] defines Metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute” 200

201 SOFTWARE MEASUREMENT… There are two types of measurement:-There are two types of measurement:- 1.Direct Measurement 2.Indirect Measurement Entities of S/W Measurement. Three basic entities of S/W need to be measured and controlled:-Entities of S/W Measurement. Three basic entities of S/W need to be measured and controlled:- 1.Process 2.Product 3.Project 201

202 MEASUREMENT CRITERIA A successful measurement program should have the following key characteristics:-A successful measurement program should have the following key characteristics:- –Objective and repeatable –Timely –Iterative –Related to information needs 202

203 MEASUREMENT PROCESS Key stages:-Key stages:- –Plan measurement –Perform measurement –Evaluate measurement –Provide Feedback 203

204 SOFTWARE METRICS A software metric is a quantifiable measure that could be used to measure different characteristics of a S/W or S/W development process.A software metric is a quantifiable measure that could be used to measure different characteristics of a S/W or S/W development process. We need metrics to quantify the:-We need metrics to quantify the:- –Development –Operationand –Maintenance of S/W 204

205 CLASSIFICATION OF S/W METRICS 1.S/W Product metrics 2.S/W Process metrics 3.S/W Project metrics 205

206 NEED FOR S/W METRICS S/W metrics are needed to answer the following:-S/W metrics are needed to answer the following:- 1.How long will it take to complete the project? 2.How much will it cost to complete the project? 3.How many persons and other resources would be required? 4.What would be the likely maintenance cost? 5.What and how to test for better quality? 6.When can the S/W be released? 7.How many errors will be discovered before delivering the product? 8.How much effort would be required to make modifications? 206

207 SOME STANDARD PRODUCT METRICS Size Metrics.Size Metrics. –Lines of Code LOC) –Token Metrics –Function Point and Extended Function Point –Bang Metrics Code complexity metrics.Code complexity metrics. –Cyclomatic Complexity –Information flow 207

208 LOC Size Metrics.S/W size estimation is the process of predicting the size of a S/W product.Size Metrics.S/W size estimation is the process of predicting the size of a S/W product. Lines of Code (LOC).Simplest metric for estimating the effort and size of a computer program.Lines of Code (LOC).Simplest metric for estimating the effort and size of a computer program. Advantages.Simple to measure.Advantages.Simple to measure. Disadvantages.Disadvantages. 1.It is programming language dependent. 2.Does not accommodate non-procedural languages. 3.Poor S/W design may lead to excessive and unnecessary lines of code. 208

209 TOKEN METRICS 1.Major drawback of LOC size measure: –It treats all the lines alike. 2.In program there are some lines which are more difficult to code than others. 3.One solution to this drawback may be to count the basic symbols used in a line instead of lines themselves. 4.These basic symbols are called Tokens, which are classified as either operators or operands. 5.For example:while, for, eof etc are all tokens. 209

210 TOKEN METRICS M.H. Halstead, proposed one of the token metric where the size of a program, which consists of the number of unique tokens can be defined in terms of :M.H. Halstead, proposed one of the token metric where the size of a program, which consists of the number of unique tokens can be defined in terms of : N1 = count of unique operators N2 = count of unique operands Length of program in terms of total number of tokens used isLength of program in terms of total number of tokens used is N = N1+N2 –Where N1 = Count of total occurrences of operators N2 = Count of total occurrences of operands 210

211 TOKEN METRICS An operator, is any symbol or keyword in a program that specifies an action.An operator, is any symbol or keyword in a program that specifies an action. Operators consist of:-Operators consist of:- symbols such as +, -, /, *,symbols such as +, -, /, *, command names such as ‘while’, ‘for’command names such as ‘while’, ‘for’and special symbols such asspecial symbols such as braces, punctuation marks etc. An operand includes variables, constants and labels.An operand includes variables, constants and labels. 211

212 FUNCTION POINT METRICS 212

213 FUNCTION POINT Function Point(FP) was developed by Allan J. Albrecht in mid 1970’s.Function Point(FP) was developed by Allan J. Albrecht in mid 1970’s. It was an attempt to overcome difficulties associated with LOC as a measure of S/W size, and to assist in developing a mechanism to predict effort associated with S/W development.It was an attempt to overcome difficulties associated with LOC as a measure of S/W size, and to assist in developing a mechanism to predict effort associated with S/W development. FP basically is an objective and structured technique to measure S/W size by quantifying its functionality provided to the user based on the requirements and logical design.FP basically is an objective and structured technique to measure S/W size by quantifying its functionality provided to the user based on the requirements and logical design. This technique breaks the system into smaller components so that they can be better understood and analysed.This technique breaks the system into smaller components so that they can be better understood and analysed. 213

214 FUNCTION POINT FP analysis, thus divides the system into five basic components namely:-FP analysis, thus divides the system into five basic components namely:- 1. External Inputs 2. External Outputs 3. Queries 4. Logical Master File ( Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted. Eg StudentMasterTable, FacultyMasterTable etc) 5.Interface File: It is a file or input-output data that is used by another application. These five components under FP analysis are rated as Simple, Average or Complex.These five components under FP analysis are rated as Simple, Average or Complex. 214

215 FUNCTION POINT 215 Type of Component SimpleAverageComplexTotal 1. External Inputs...x3 = … …x4=……x6=…= 2. External Outputs...x4 = … …x5=……x7=…= 3. Queries...x3 = … …x4=……x6=…= 4. Logical Master Files...x7 = … …x10=……x15=…= 5. Interface File...x5 = … …x7=……x10=…= Count Total = Computing Count Total for FP

216 FUNCTION POINT To compute Function Point, the following relationship is used:To compute Function Point, the following relationship is used: FP = (Count Total) x [ x ∑(Fi)] The Fi (i = 1 to 14) are complexity adjustment values based on the response to the following questions:The Fi (i = 1 to 14) are complexity adjustment values based on the response to the following questions: 216

217 Weightage Each of the following questions is answered using a scale that ranges fromEach of the following questions is answered using a scale that ranges from 0 (not important or applicable) to0 (not important or applicable) to 5 (absolutely essential).5 (absolutely essential). 217

218 FUNCTION POINT 1. Does the system require reliable backup and recovery? 2. Are data communications required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilised operational environment? 6. Does the system require on-line data entry? 7. Does the on-line data entry require the input transcation to be built over multiple screens or operations? 218

219 FUNCTION POINT 8.Are the master files updated on-line? 9.Are the inputs, outputs, files or queries 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 organisations? 14.Is the application designed to facilitate change and ease of use by the user? 219

220 FUNCTION POINT After the counts for each level of complexity for each type of component are entered, each counter is multiplied by the numerical rating.After the counts for each level of complexity for each type of component are entered, each counter is multiplied by the numerical rating. The rated values on each row are totalled.The rated values on each row are totalled. These totals are then summed down to arrive at the Count Total.These totals are then summed down to arrive at the Count Total. 220

221 FUNCTION POINT Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential).Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential). The constant values in EquationThe constant values in Equation FP = (Count Total) x [ x ∑(Fi)] and the weighting factors that are applied to information domain counts are determined empirically. 221

222 FUNCTION POINT Once function points have been calculated,Once function points have been calculated, they are used in a manner analogous to LOC as a way to normalize measures for software productivity, quality, and other attributes: Errors per FP.Errors per FP. Defects per FP.Defects per FP. $ per FP.$ per FP. Pages of documentation per FP.Pages of documentation per FP. FP per person-month.FP per person-month. 222

223 FUNCTION POINT ADVANTAGES Advantages of Function PointAdvantages of Function Point 1.Function points can be used to size software applications accurately. 2.They can be counted by different peopleby different people at different timesat different times to obtain the same measure within a reasonable margin of error.to obtain the same measure within a reasonable margin of error. 3.FP are easily understood by non-technical user. This helps to communicate sizing information to a user or customer. 4.FP can be used to determine whether a tool, a language, an environment is more productive when compared with others. 5.FPs are language independent and can be computed early in a project. 6.Due to these advantages, function points are becoming widely accepted as the standard metric for measuring software size. 223

224 QUALITY METRICS Correctness.Correctness. –Defects per KLOC –Defects are counted over a standard period of time Maintainability.Maintainability. –Ease with which a program can be corrected if an error is encountered –There is no direct method –We measure it indirectly Mean Time To Change (MTTC)Mean Time To Change (MTTC) 224

225 QUALITY METRICS IntegrityIntegrity –This attribute measures a system’s ability to withstand attacks on:- ProgramsPrograms DataData DocumentsDocuments –To measure integrity, two additional attributes must be defined: Threat and Security 225

226 QUALITY METRICS Threat is the probability (which can be estimated or derived from empirical evidence) that an attack of a specific type will occur within a given time.Threat is the probability (which can be estimated or derived from empirical evidence) that an attack of a specific type will occur within a given time. Security is the probability (which can be estimated or derived from empirical evidence) that the attack of a specific type will be repelled.Security is the probability (which can be estimated or derived from empirical evidence) that the attack of a specific type will be repelled. The integrity of a system can then be defined asThe integrity of a system can then be defined as Integrity = Summation[(1-threat) x (1-security)] (where threat and security are summed over each type of attack. i.e. attack on Programs, Data and Documents) 226

227 QUALITY METRICS Usability.Usability. 1.Physical and or intellectual skill required to learn the system 2.Time required to become moderately efficient 3.The net increase in productivity measured when the system is used by someone who is moderately efficient 4.A subjective assessment of users attitude towards the system. 227

228 COMPONENTS OF SOFTWARE* 1.Set of instructions 2.Operating procedures 3.Data Structures 4.Documentation. Design/Architecture documentation (Architecture: A style and method of design and construction; Architectural design represents the structure of data and program components that are required to build a computer-based system.) Design/Architecture documentation (Architecture: A style and method of design and construction; Architectural design represents the structure of data and program components that are required to build a computer-based system.) Technical DocumentationTechnical Documentation End-User DocumentationEnd-User Documentation 228

229 DATA CENTRED ARCHITECTURE 229 E.g. University Results for viewing by public

230 DATA FLOW ARCHITECTURE 230 E.g. Processing of student data for preparing University Results

231 LAYERED ARCHITECTURE 231

232 OTHER APPLICATIONS OF SOFTWARE 1.Real Time S/W 2.Embedded S/W 3.Edutainment S/W 4.Communications S/W 5.Utility S/W 232

233 CONCEPTS OF PROJECT MANAGEMENT… 5.The Software Project Management becomes all the more important and particularly difficult due to the following reasons:- –S/W Product is Intangible (unable to be touched) –There is no standard process –New S/W projects are not similar to previous ones. 233

234 FOUR P’s IN PROJECT MANAGEMENT Four P’s in Project Management:-Four P’s in Project Management:- 1.People 2.Product 3.Process 4.Project 234

235 CONCEPTS OF PROJECT MANAGEMENT (AS PER ROGER S PRESSMAN) 235

236 CONCEPTS OF ROJECT MANAGEMENT Project management involves:-Project management involves:- –planning, –monitoring, and –control of the  people,  process,  and events that occur as software evolves from a preliminary concept to an operational implementation. that occur as software evolves from a preliminary concept to an operational implementation. 236

237 CONCEPTS OF PROJECT MANAGEMENT Who does it?Who does it? 1.A software engineer manages his day- to-day activities:-1.A software engineer manages his day- to-day activities:-  planning, monitoring, and controlling technical tasks. 2.Project managers plan, monitor, and control the work of a team of software engineers.2.Project managers plan, monitor, and control the work of a team of software engineers. 3.Senior managers coordinate the interface between the business and the software professionals.3.Senior managers coordinate the interface between the business and the software professionals. 237

238 CONCEPTS OF ROJECT MANAGEMENT Why is it important?Why is it important? –Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time. –That’s why software projects need to be managed. 238

239 CONCEPTS OF ROJECT MANAGEMENT What are the steps? Understand the four P’s—Understand the four P’s— –people, –product, –process, –and project. 1.People.People must be organized to perform software work effectively. 2.Product. Communication with the customer must occur so that product scope and requirements are understood. 239

240 CONCEPTS OF ROJECT MANAGEMENT 3.Process.A process must be selected that is appropriate for the people and the product. 4.Project. The project must be planned by estimating effort and calendar time to accomplish work tasks:- – defining work products, – establishing quality checkpoints, and – establishing mechanisms to monitor and control work defined by the plan. 240

241 CONCEPTS OF ROJECT MANAGEMENT What is the work product? A project plan is produced as management activities commence.A project plan is produced as management activities commence. The plan defines:-The plan defines:- –the process and tasks to be conducted, –the people who will do the work, –and the mechanisms for:-  assessing risks,  controlling change, and  evaluating quality. 241

242 CONCEPTS OF ROJECT MANAGEMENT How do I ensure that I’ve done it right?How do I ensure that I’ve done it right? You’re never completely sure that the project plan is right until you’ve delivered a high- quality product on time and within budget.You’re never completely sure that the project plan is right until you’ve delivered a high- quality product on time and within budget. However, a project manager does it right when:-However, a project manager does it right when:- –he encourages software people:-  to work together as an effective team,  focusing their attention on:-  customer needs and product quality. 242

243 FOUR P’s IN PROJECT MANAGEMENT 1.People1.People 1.Senior Managers 2.Project Managers 3.Programmers 4.Customers 5.End users 243

244 FOUR P’s IN PROJECT MANAGEMENT… 1.People…1.People… 1.Senior Managers:They define the business issues that have significant influence on the project.1.Senior Managers:They define the business issues that have significant influence on the project. 2.Project Managers:They plan, motivate, organise and control the programmers who do S/W work.2.Project Managers:They plan, motivate, organise and control the programmers who do S/W work. 3.Programmers:They use technical skills to develop a product.3.Programmers:They use technical skills to develop a product. 4.Customers:They are generally heads of the organisations who specify the needs of the organisation for automation.4.Customers:They are generally heads of the organisations who specify the needs of the organisation for automation. 5.End Users:They would be generally clerks, operators etc. who actually use the S/W. Some functions of the S/W are also used by people higher in chain of command.5.End Users:They would be generally clerks, operators etc. who actually use the S/W. Some functions of the S/W are also used by people higher in chain of command. 244

245 FOUR P’s IN PROJECT MANAGEMENT Project Manager.Project Manager. 1.Motivation 2.Organisation 3.Innovation 4.Problem Solving 5.Managerial Capabilities 6.Leadership Skills 7.Influence and Team Building 245

246 FOUR P’s IN PROJECT MANAGEMENT Programmers/The Software Team.Programmers/The Software Team. 1.Democratic or Egoless Team.1.Democratic or Egoless Team. 2.Controlled Centralised or Chief Programmer Team2.Controlled Centralised or Chief Programmer Team 3.Controlled Decentralised Team3.Controlled Decentralised Team 246

247 FOUR P’s IN PROJECT MANAGEMENT 1. Democratic or Egoless Team.1. Democratic or Egoless Team. 247

248 FOUR P’s IN PROJECT MANAGEMENT Programmers/ The Software Team…Programmers/ The Software Team… 2.Controlled Centralised or Chief Programmer Team2.Controlled Centralised or Chief Programmer Team 248

249 FOUR P’s IN PROJECT MANAGEMENT Programmers/The Software Team.Programmers/The Software Team. 3.Controlled Decentralised Team.3.Controlled Decentralised Team. –This structure tries to combine the strengths of democratic and controlled centralised teams. –It has a Project Leader who has a group of senior programmers under him. –Under each senior programmer is a group of junior programmers. 249

250 FOUR P’s IN PROJECT MANAGEMENT Programmers/ The Software Team.Programmers/ The Software Team. 1.Democratic or Egoless Team.1.Democratic or Egoless Team. –Upto 10 programmers –Goals set by consensus –Inputs from every member are taken for major decisions –Group leadership rotates among team members –Not suitable for:- oComplex tasks oTasks with time constraints, Results in inefficiency 250

251 FOUR P’s IN PROJECT MANAGEMENT Programmers/ The Software Team.Programmers/ The Software Team. 2.Controlled Centralised or Chief Programmer Team.2.Controlled Centralised or Chief Programmer Team. –Follows a hierarchy –There is a chief programmer with:-  Backup programmer  Program librarian for maintaining documentation and other communication related work –Reduced inter-personal communication –Suitable for projects with:-  Simple solutions  Strict deadlines –Not suitable for difficult tasks where multiple inputs are useful. 251

252 Programmers/The Software Team.Programmers/The Software Team. 3.Controlled Decentralised Team3.Controlled Decentralised Team 1.Tries to combine the strengths of democratic and controlled centralised teams. 2.Consists of:- –Project leader with senior programmers under him. –Under each senior programmer:- »a group of junior programmers. »This forms a democratic team »Communication among different groups occurs through senior programmers of respective groups. –Senior programmers also communicate with project leader 3.Fewer communication paths than democratic but more than controlled centralised. 4.Best for large projects that are straight forward. 5.Not well suited for simple projects or research projects. 252

253 PROJECT FACTORS FOR PLANNING SOFTWARE TEAM 1.Difficulty of problem to be solved. 2.Size of resultant program(s) in Lines of Code or Function Points. 3.The time that the team will stay together. 4.Degree to which the problem can be modularised. 5.Required quality and reliability of the system to be built. 6.Rigidity of delivery date. 7.Degree of communication required for the project. 253

254 FOUR P’s IN PROJECT MANAGEMENT 2.The Product.2.The Product. –Software scope must be established and bounded at the very beginning. –Problem Decomposition. 254

255 FOUR P’s IN PROJECT MANAGEMENT 3.The Process.3.The Process. –Generic phases that characterise the software process applicable to all S/W:- DefinitionDefinition DevelopmentDevelopment SupportSupport –Select suitable process model from:- Linear/Life cycleLinear/Life cycle PrototypingPrototyping SpiralSpiral 4GT Model4GT Model –Define project plan based on common process framework activities 255

256 FOUR P’s IN PROJECT MANAGEMENT 4.The Project.4.The Project. –What can go wrong? –How to do it right? –Problem Indicators:- 1.Customer’s needs 2.Scope 3.Changes managed poorly 4.Chosen technology changes 5.Business needs change 6.Deadlines are unrealistic 7.Users are resistant 8.Lacking of appropriate skills 256

257 FOUR P’s IN PROJECT MANAGEMENT The Project.The Project. –How to do it right? 1.Start on the right foot 2.Maintain momentum 3.Track progress 4.Keep it simple 5.Conduct a post-mortem analysis 257

258 PROJECT MANAGEMENT ACTIVITIES 1.Measurement and metrics1.Measurement and metrics 2.Management activities2.Management activities 3.Project planning3.Project planning 4.Scheduling4.Scheduling 5.Tracking5.Tracking 6.Risk management6.Risk management These are umbrella activitiesThese are umbrella activities 258

259 ROLE OF METRICS* 259

260 HOW TO CALULATE COST Cost is generally based on:- Cost is generally based on:- – Utility – Quantity – Quality – Effort involved – Degree of difficulty – Ease of use – Aesthetics 260

261 ROLE OF METRICS Metrics: A standard of measurement Metrics: A standard of measurement For example:- For example:- – Metrics for solids:Weight (kg, gm etc) – Metrics for liquids:Litre, ml etc. – Metrics for gases:Cubic meters, cc etc. – Metrics for length:meter, cm etc. 261

262 ROLE OF METRICS… When you can measure what you are speaking about and express it in numbers, you know something about it;When you can measure what you are speaking about and express it in numbers, you know something about it; –but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meagre ( deficient or inferior ) and unsatisfactory kind:-  it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of a science.- Lord Kelvin 262

263 ROLE OF METRICS… What is metrics?What is metrics? Software process and product metrics are quantitative measures ( measure: size or quantity as ascertained or ascertainable by measuring ) that enable software people:-Software process and product metrics are quantitative measures ( measure: size or quantity as ascertained or ascertainable by measuring ) that enable software people:- –to gain insight into the efficacy of the:- software process and thesoftware process and the projects that are conductedprojects that are conducted using the process as a framework.using the process as a framework. 263

264 ROLE OF METRICS… What is metrics? …What is metrics? … Basic quality and productivity data are collected.Basic quality and productivity data are collected. These data are then:-These data are then:- –analyzed, –compared against past averages, and –assessed to determine:-  whether quality and productivity improvements have occurred. Metrics are also used to pinpoint problem areas so that remedies can be developed and the software process can be improved.Metrics are also used to pinpoint problem areas so that remedies can be developed and the software process can be improved. 264

265 ROLE OF METRICS… Who does it?Who does it? Software metrics are:-Software metrics are:- –analyzed and –assessed by software managers.software managers. Measures are often collected by software engineers.Measures are often collected by software engineers. (Meter rod is a measure, Measuring cloth is measurement. In case of Software: size, No. of functions, No. of Inputs, Outputs etc are measures.) (Meter rod is a measure, Measuring cloth is measurement. In case of Software: size, No. of functions, No. of Inputs, Outputs etc are measures.) 265

266 ROLE OF METRICS… Why is it important?Why is it important? If you don’t measure, judgement can be based only on subjective evaluation.If you don’t measure, judgement can be based only on subjective evaluation. With measurement:-With measurement:- – trends (either good or bad) can be spotted, – better estimates can be made, and –true improvement can be accomplished over time. 266

267 ROLE OF METRICS… What are the steps?What are the steps? Begin by defining a limited set of:-Begin by defining a limited set of:- –process, –project, and –product measures that are  easy to collect. –These measures are often normalized (made equal to a particular value) using:- either size- oreither size- or function-oriented metrics.function-oriented metrics. The result is analyzed and compared to past averages for similar projects performed within the organization.The result is analyzed and compared to past averages for similar projects performed within the organization. Trends are assessed and conclusions are generated.Trends are assessed and conclusions are generated. 267

268 ROLE OF METRICS… What is the work product?What is the work product? A set of software metrics that provide insight into theA set of software metrics that provide insight into the –process and –understanding of the project. ( A software metric is a measure of some property of a piece of software or its specifications.( A software metric is a measure of some property of a piece of software or its specifications.) 268

269 ROLE OF METRICS… How do I ensure that I’ve done it right?How do I ensure that I’ve done it right? By applying a consistent, yet simple measurement scheme that is never to be used to assess, reward, or punish individual performance.By applying a consistent, yet simple measurement scheme that is never to be used to assess, reward, or punish individual performance. 269

270 ROLE OF METRICS… The discipline of software engineering uses the concept of measurement, which enables software managers to:-The discipline of software engineering uses the concept of measurement, which enables software managers to:- –determine the cost and effort devoted to project. –assess software quality. –understand and improve the software process. –Predict, plan and control the software projects. 270

271 SOFTWARE MEASUREMENT… Measures, Metrics and Indicators:-Measures, Metrics and Indicators:- –Measure: A measure provides a quantitative indication of the:- ExtentExtent AmountAmount DimensionDimension CapacityorCapacityor SizeSize of some attribute of a product or process. –Measurement: is the act of determining a measure. –Metric: The IEEE Standard Glossary[IEE93] defines Metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute” 271

272 SOFTWARE MEASUREMENT… There are two types of measurement:-There are two types of measurement:- 1.Direct Measurement 2.Indirect Measurement Entities of S/W Measurement. Three basic entities of S/W need to be measured and controlled:-Entities of S/W Measurement. Three basic entities of S/W need to be measured and controlled:- 1.Process 2.Product 3.Project 272

273 MEASUREMENT CRITERIA A successful measurement program should have the following key characteristics:-A successful measurement program should have the following key characteristics:- –Objective and repeatable –Timely –Iterative –Related to information needs 273

274 MEASUREMENT PROCESS Key stages:-Key stages:- –Plan measurement –Perform measurement –Evaluate measurement –Provide Feedback 274

275 SOFTWARE METRICS A software metric is a quantifiable measure that could be used to measure different characteristics of a S/W or S/W development process.A software metric is a quantifiable measure that could be used to measure different characteristics of a S/W or S/W development process. We need metrics to quantify the:-We need metrics to quantify the:- –Development –Operationand –Maintenance of S/W 275

276 CLASSIFICATION OF S/W METRICS 1.S/W Product metrics 2.S/W Process metrics 3.S/W Project metrics 276

277 NEED FOR S/W METRICS S/W metrics are needed to answer the following:-S/W metrics are needed to answer the following:- 1.How long will it take to complete the project? 2.How much will it cost to complete the project? 3.How many persons and other resources would be required? 4.What would be the likely maintenance cost? 5.What and how to test for better quality? 6.When can the S/W be released? 7.How many errors will be discovered before delivering the product? 8.How much effort would be required to make modifications? 277

278 SOME STANDARD PRODUCT METRICS Size Metrics.Size Metrics. –Lines of Code LOC) –Token Metrics –Function Point and Extended Function Point –Bang Metrics Code complexity metrics.Code complexity metrics. –Cyclomatic Complexity –Information flow 278

279 LOC Size Metrics.S/W size estimation is the process of predicting the size of a S/W product.Size Metrics.S/W size estimation is the process of predicting the size of a S/W product. Lines of Code (LOC).Simplest metric for estimating the effort and size of a computer program.Lines of Code (LOC).Simplest metric for estimating the effort and size of a computer program. Advantages.Simple to measure.Advantages.Simple to measure. Disadvantages.Disadvantages. 1.It is programming language dependent. 2.Does not accommodate non-procedural languages. 3.Poor S/W design may lead to excessive and unnecessary lines of code. 279

280 TOKEN METRICS 1.Major drawback of LOC size measure: –It treats all the lines alike. 2.In program there are some lines which are more difficult to code than others. 3.One solution to this drawback may be to count the basic symbols used in a line instead of lines themselves. 4.These basic symbols are called Tokens, which are classified as either operators or operands. 5.For example:while, for, eof etc are all tokens. 280

281 TOKEN METRICS M.H. Halstead, proposed one of the token metric where the size of a program, which consists of the number of unique tokens can be defined in terms of :M.H. Halstead, proposed one of the token metric where the size of a program, which consists of the number of unique tokens can be defined in terms of : N1 = count of unique operators N2 = count of unique operands Length of program in terms of total number of tokens used isLength of program in terms of total number of tokens used is N = N1+N2 –Where N1 = Count of total occurrences of operators N2 = Count of total occurrences of operands 281

282 TOKEN METRICS An operator, is any symbol or keyword in a program that specifies an action.An operator, is any symbol or keyword in a program that specifies an action. Operators consist of:-Operators consist of:- – symbols such as +, -, /, *, – command names such as ‘while’, ‘for’ and – special symbols such as braces, punctuation marks etc. An operand includes variables, constants and labels.An operand includes variables, constants and labels. 282

283 FUNCTION POINT METRICS 283

284 FUNCTION POINT Function Point(FP) was developed by Allan J. Albrecht in mid 1970’s.Function Point(FP) was developed by Allan J. Albrecht in mid 1970’s. It was an attempt to overcome difficulties associated with LOC as a measure of S/W size, and to assist in developing a mechanism to predict effort associated with S/W development.It was an attempt to overcome difficulties associated with LOC as a measure of S/W size, and to assist in developing a mechanism to predict effort associated with S/W development. FP basically is an objective and structured technique to measure S/W size by quantifying its functionality provided to the user based on the requirements and logical design.FP basically is an objective and structured technique to measure S/W size by quantifying its functionality provided to the user based on the requirements and logical design. This technique breaks the system into smaller components so that they can be better understood and analysed.This technique breaks the system into smaller components so that they can be better understood and analysed. 284

285 FUNCTION POINT FP analysis, thus divides the system into five basic components namely:-FP analysis, thus divides the system into five basic components namely:- 1. External Inputs 2. External Outputs 3. Queries 4. Logical Master File ( Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted. Eg StudentMasterTable, FacultyMasterTable etc) 5.Interface File: It is a file or input-output data that is used by another application. These five components under FP analysis are rated as Simple, Average or Complex.These five components under FP analysis are rated as Simple, Average or Complex. 285

286 FUNCTION POINT 286 Type of Component SimpleAverageComplexTotal 1. External Inputs...x3 = … …x4=……x6=…= 2. External Outputs...x4 = … …x5=……x7=…= 3. Queries...x3 = … …x4=……x6=…= 4. Logical Master Files...x7 = … …x10=……x15=…= 5. Interface File...x5 = … …x7=……x10=…= Count Total = Computing Count Total for FP

287 FUNCTION POINT To compute Function Point, the following relationship is used:To compute Function Point, the following relationship is used: FP = (Count Total) x [ x ∑(Fi)] The Fi (i = 1 to 14) are complexity adjustment values based on the response to the following questions:The Fi (i = 1 to 14) are complexity adjustment values based on the response to the following questions: 287

288 Weightage Each of the following questions is answered using a scale that ranges from Each of the following questions is answered using a scale that ranges from – 0 (not important or applicable) to – 5 (absolutely essential). 288

289 FUNCTION POINT 1. Does the system require reliable backup and recovery? 2. Are data communications required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilised operational environment? 6. Does the system require on-line data entry? 7. Does the on-line data entry require the input transcation to be built over multiple screens or operations? 289

290 FUNCTION POINT 8.Are the master files updated on-line? 9.Are the inputs, outputs, files or queries 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 organisations? 14.Is the application designed to facilitate change and ease of use by the user? 290

291 FUNCTION POINT After the counts for each level of complexity for each type of component are entered, each counter is multiplied by the numerical rating.After the counts for each level of complexity for each type of component are entered, each counter is multiplied by the numerical rating. The rated values on each row are totalled.The rated values on each row are totalled. These totals are then summed down to arrive at the Count Total.These totals are then summed down to arrive at the Count Total. 291

292 FUNCTION POINT Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential). Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential). The constant values in Equation The constant values in Equation FP = (Count Total) x [ x ∑(Fi)] and the weighting factors that are applied to information domain counts are determined empirically. 292

293 FUNCTION POINT Once function points have been calculated, Once function points have been calculated, they are used in a manner analogous to LOC as a way to normalize measures for software productivity, quality, and other attributes: – Errors per FP. – Defects per FP. – $ per FP. – Pages of documentation per FP. – FP per person-month. 293

294 FUNCTION POINT ADVANTAGES Advantages of Function PointAdvantages of Function Point 1.Function points can be used to size software applications accurately. 2.They can be counted by different peopleby different people at different timesat different times to obtain the same measure within a reasonable margin of error.to obtain the same measure within a reasonable margin of error. 3.FP are easily understood by non-technical user. This helps to communicate sizing information to a user or customer. 4.FP can be used to determine whether a tool, a language, an environment is more productive when compared with others. 5.FPs are language independent and can be computed early in a project. 6.Due to these advantages, function points are becoming widely accepted as the standard metric for measuring software size. 294

295 QUALITY METRICS 295

296 QUALITY METRICS Correctness.Correctness. –Defects per KLOC –Defects are counted over a standard period of time Maintainability.Maintainability. –Ease with which a program can be corrected if an error is encountered –There is no direct method –We measure it indirectly Mean Time To Change (MTTC)Mean Time To Change (MTTC) 296

297 QUALITY METRICS IntegrityIntegrity –This attribute measures a system’s ability to withstand attacks on:- ProgramsPrograms DataData DocumentsDocuments –To measure integrity, two additional attributes must be defined: Threat and Security 297

298 QUALITY METRICS – Threat is the probability (which can be estimated or derived from empirical evidence) that an attack of a specific type will occur within a given time. – Security is the probability (which can be estimated or derived from empirical evidence) that the attack of a specific type will be repelled. – The integrity of a system can then be defined as Integrity = Summation[(1-threat) x (1-security)] (where threat and security are summed over each type of attack. i.e. attack on Programs, Data and Documents) 298

299 QUALITY METRICS Usability.Usability. 1.Physical and or intellectual skill required to learn the system 2.Time required to become moderately efficient 3.The net increase in productivity measured when the system is used by someone who is moderately efficient 4.A subjective assessment of users attitude towards the system. 299

300 PROJECT MANAGEMENT The application of knowledge, skills, tools and techniques to a broad range of activities in order to meet the requirements of a particular project.“The application of knowledge, skills, tools and techniques to a broad range of activities in order to meet the requirements of a particular project.“ The process of directing and controlling a project from start to finish may be further divided into 5 basic phases:The process of directing and controlling a project from start to finish may be further divided into 5 basic phases: 1.Project Conception and Initiation. An idea for a project will be carefully examined to determine whether or not it benefits the organization. During this phase, a decision making team will identify if the project can realistically be completed.An idea for a project will be carefully examined to determine whether or not it benefits the organization. During this phase, a decision making team will identify if the project can realistically be completed. 2. Project Definition and Planning. A project plan, project charter and/or project scope may be put in writing, outlining the work to be performed.A project plan, project charter and/or project scope may be put in writing, outlining the work to be performed. During this phase, a team should prioritize the project, calculate a budget and schedule, and determine what resources are needed.During this phase, a team should prioritize the project, calculate a budget and schedule, and determine what resources are needed. 300

301 PROJECT MANAGEMENT 2. Project definition and planning. A project plan, project charter and/or project scope may be put in writing, outlining the work to be performed. During this phase, a team should prioritize the project, calculate a budget and schedule, and determine what resources are needed.A project plan, project charter and/or project scope may be put in writing, outlining the work to be performed. During this phase, a team should prioritize the project, calculate a budget and schedule, and determine what resources are needed. 3. Project launch or execution Resources' tasks are distributed and teams are informed of responsibilities. This is a good time to bring up important project related information.Resources' tasks are distributed and teams are informed of responsibilities. This is a good time to bring up important project related information. 4. Project performance and control Project managers will compare project status and progress to the actual plan, as resources perform the scheduled work. During this phase, project managers may need to adjust schedules or do what is necessary to keep the project on track.Project managers will compare project status and progress to the actual plan, as resources perform the scheduled work. During this phase, project managers may need to adjust schedules or do what is necessary to keep the project on track. 301

302 PROJECT MANAGEMENT 5. Project close. After project tasks are completed and the client has approved the outcome, an evaluation is necessary to highlight project success and/or learn from project history.After project tasks are completed and the client has approved the outcome, an evaluation is necessary to highlight project success and/or learn from project history. Projects and project management processes vary from industry to industry; however, these are more traditional elements of a project. The overarching goal is typically to offer a product, change a process or to solve a problem in order to benefit the organization.Projects and project management processes vary from industry to industry; however, these are more traditional elements of a project. The overarching goal is typically to offer a product, change a process or to solve a problem in order to benefit the organization. 302

303 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Facilitated Application Specific Techniques (FAST)… Facilitated Application Specification Technique ("FAST") is a technique for requirements elicitation for software development.Facilitated Application Specification Technique ("FAST") is a technique for requirements elicitation for software development. The objective is to close the gap between what the developers intend and what users expect.The objective is to close the gap between what the developers intend and what users expect. It is a team-oriented approach for gathering requirements.It is a team-oriented approach for gathering requirements. Basic guidelines:-Basic guidelines:- 1.Meetings are conducted at a neutral site attended by both developers and users. 2.The group establishes rules for preparation and participation. 3.An agenda is suggested with enough formality to cover all important points but informal enough to encourage the free flow of ideas. 4.A facilitator controls the meeting. 5.A definition mechanism is used. 303

304 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Facilitated Application Specific Techniques (FAST)… The main goal isThe main goal is 1.to identify the problem, 2.propose solutions, 3.negotiate different approaches, and 4.specify a preliminary set of software requirements in an atmosphere that is conducive ( contributive ) to accomplish the goal. 304

305 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Facilitated Application Specific Techniques (FAST)… After initial meeting, user and developer should write one or two product request forms.After initial meeting, user and developer should write one or two product request forms. Before the next meeting it is distributed to all other attendees. Each attendee is asked to make the following lists:Before the next meeting it is distributed to all other attendees. Each attendee is asked to make the following lists: List of objectsList of objects List of servicesList of services List of constraintsList of constraints Performance criteriaPerformance criteria Representatives of FASTRepresentatives of FAST Marketing personMarketing person Software and hardware engineerSoftware and hardware engineer Representative from manufacturingRepresentative from manufacturing An outside facilitatorAn outside facilitator 305

306 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Requirements Elicitation and Analysis… This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system.This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. REQUIREMENT ELICITATION METHODS… Joint Application Design (JAD) JAD is a process, similar to brainstorming, which captures requirements at a high level, but specific abstraction.JAD is a process, similar to brainstorming, which captures requirements at a high level, but specific abstraction. JAD sessions are very popular in the industry and typically last three days. In this time, participants generate ideas that are captured by facilitators. These ideas are fleshed out with the use of tools. Data Flow Diagrams (DFDs) and Entity Relationship Diagrams (ERDs) are two common graphical methods for exploring the generated ideas.JAD sessions are very popular in the industry and typically last three days. In this time, participants generate ideas that are captured by facilitators. These ideas are fleshed out with the use of tools. Data Flow Diagrams (DFDs) and Entity Relationship Diagrams (ERDs) are two common graphical methods for exploring the generated ideas. While JAD sessions are a good way to get a detailed list of requirements that have been thought out, Futrell et al. (2002) points out three disadvantages:While JAD sessions are a good way to get a detailed list of requirements that have been thought out, Futrell et al. (2002) points out three disadvantages: 306

307 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Requirements Elicitation and Analysis… This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system.This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. REQUIREMENT ELICITATION METHODS… Joint Application Design (JAD)… While JAD sessions are a good way to get a detailed list of requirements that have been thought out, Futrell et al. (2002) points out three disadvantages:While JAD sessions are a good way to get a detailed list of requirements that have been thought out, Futrell et al. (2002) points out three disadvantages: There is a possibility for misinterpretation by the facilitator in recording ideasThere is a possibility for misinterpretation by the facilitator in recording ideas The approach mainly deals with data elements and screen designs, rather than real time requirement issuesThe approach mainly deals with data elements and screen designs, rather than real time requirement issues The sessions can be a costly exercise for both software developer and customerThe sessions can be a costly exercise for both software developer and customer 307

308 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Requirements Elicitation and Analysis… This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system.This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. REQUIREMENT ELICITATION METHODS… User scenarios / use case development sessions These describe what a system will do. Actors interact with events to show what the system will perform in a particular case. Actors can be users, databases, or other systems. Events might include calculating the balance of an actors account, or interfacing with a different system.These describe what a system will do. Actors interact with events to show what the system will perform in a particular case. Actors can be users, databases, or other systems. Events might include calculating the balance of an actors account, or interfacing with a different system. By going through each possible case the system will be in (often graphically, with use case diagrams), a good knowledge of the customers business will emerge. Those who use the system (the actors) need to be a part of this process, so a focus is placed on them and their needs.By going through each possible case the system will be in (often graphically, with use case diagrams), a good knowledge of the customers business will emerge. Those who use the system (the actors) need to be a part of this process, so a focus is placed on them and their needs. 308

309 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Requirements Elicitation and Analysis… This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system.This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. REQUIREMENT ELICITATION METHODS… Requirements management Once the initial requirements have been agreed upon, other requirements are likely to be uncovered as the project progresses. How these are dealt with is important. If they are ignored by the developer, then the quality of the final system is likely to be severely reduced. If every single requirement suggested is tacked on to the system, quality is also likely to suffer, with additions and modifications done improperly.Once the initial requirements have been agreed upon, other requirements are likely to be uncovered as the project progresses. How these are dealt with is important. If they are ignored by the developer, then the quality of the final system is likely to be severely reduced. If every single requirement suggested is tacked on to the system, quality is also likely to suffer, with additions and modifications done improperly. Configuration management can be used to manage requirements. Baselines are established and any modifications to those requirements must be signed off.Configuration management can be used to manage requirements. Baselines are established and any modifications to those requirements must be signed off. 309

310 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Requirements Elicitation and Analysis… This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system.This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. REQUIREMENT ELICITATION METHODS… Requirements management… Prototyping is a great method to use for a situation where requirements are unclear and are likely to be uncovered as the project progresses. A mock up of a system is created on a small scale to demonstrate the basic functionality. Users can interact with this prototype to determine what is required. At the completion of the prototype, it is discarded and development begins from scratch. This time however, the system requirements will have been clarified significantly.Prototyping is a great method to use for a situation where requirements are unclear and are likely to be uncovered as the project progresses. A mock up of a system is created on a small scale to demonstrate the basic functionality. Users can interact with this prototype to determine what is required. At the completion of the prototype, it is discarded and development begins from scratch. This time however, the system requirements will have been clarified significantly. 310

311 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Requirements Elicitation and Analysis… This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system.This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. REQUIREMENT ELICITATION METHODS… Requirements and Quality Function Deployment Quality Function Deployment (QFD) is used to define the requirements of a product ( any product, and increasingly services ) based around the end users needs.Quality Function Deployment (QFD) is used to define the requirements of a product ( any product, and increasingly services ) based around the end users needs. This customer focus is QFD’s strength, and with the use of the relational matrix, solid customer requirements can be extracted.This customer focus is QFD’s strength, and with the use of the relational matrix, solid customer requirements can be extracted. Figure 4 ( taken from Tan et al., 1998 ) demonstrates this relational matrix (also known as the house of quality).Figure 4 ( taken from Tan et al., 1998 ) demonstrates this relational matrix (also known as the house of quality). 311

312 312

313 313

314 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Requirements Elicitation and Analysis… This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system.This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. REQUIREMENT ELICITATION METHODS… Requirements and Quality Function Deployment… Figure 4 (taken from Tan et al., 1998) demonstrates this relational matrix (also known as the house of quality).Figure 4 (taken from Tan et al., 1998) demonstrates this relational matrix (also known as the house of quality). This was constructed based on a survey of internet users on how web pages should be designed.This was constructed based on a survey of internet users on how web pages should be designed. A questionnaire was given out, with participants determining what they see as being important quality issues relating to web pages.A questionnaire was given out, with participants determining what they see as being important quality issues relating to web pages. The results of the questionnaire were then sorted into primary, secondary and tertiary requirements.The results of the questionnaire were then sorted into primary, secondary and tertiary requirements. 314

315 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Requirements Elicitation and Analysis… This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system.This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. REQUIREMENT ELICITATION METHODS… Requirements and Quality Function Deployment… Following this, the requirements were translated into technical details, listed on the vertical.Following this, the requirements were translated into technical details, listed on the vertical. These technical details are not solutions, but are in a format that a solution can be readily developed from.These technical details are not solutions, but are in a format that a solution can be readily developed from. A cross-functional team, utilising brainstorming is commonly used for this stage.A cross-functional team, utilising brainstorming is commonly used for this stage. The central matrix shows the relationship between the customer requirements and the technical details.The central matrix shows the relationship between the customer requirements and the technical details. The ‘roof’ of the house of quality gives the co-relationships between the technical details.The ‘roof’ of the house of quality gives the co-relationships between the technical details. 315

316 REQUIREMENT ELICITATION TECHNIQUES- FAST AND QFD Requirements Elicitation and Analysis… This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system.This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. REQUIREMENT ELICITATION METHODS… Requirements and Quality Function Deployment… Finally, a ranking is computed from both types of relationships using weightings.Finally, a ranking is computed from both types of relationships using weightings. This final ranking is an indicator of what technical detail is the most important issue to concentrate on and get right.This final ranking is an indicator of what technical detail is the most important issue to concentrate on and get right. It can be used:-It can be used:- to prioritise the implementation of components of a system, orto prioritise the implementation of components of a system, or to choose which parts get left in or thrown out.to choose which parts get left in or thrown out. 316

317 QUALITY FUNCTION DEPLOYMENT: QFD QFD: When and How Does it Fit in Software Development? Quality function deployment (QFD) is a tool that appeals to many engineers and designers. It looks so nifty (pleasing) that they think, “There just has to be a place to use this.”Quality function deployment (QFD) is a tool that appeals to many engineers and designers. It looks so nifty (pleasing) that they think, “There just has to be a place to use this.” Experience shows, though, that with its niftiness comes a certain risk connected with trying to apply QFD in places or in ways that it really does not fit.Experience shows, though, that with its niftiness comes a certain risk connected with trying to apply QFD in places or in ways that it really does not fit. QFD grew out of work at Bridgestone Tire and later Toyota to trace the treatment of customer-demanded quality attributes by the choices a supplier makes from design through component selection and process specification and control. Because this work dealt with manufactured products, many QFD textbook and training examples are cast in a manufacturing model.QFD grew out of work at Bridgestone Tire and later Toyota to trace the treatment of customer-demanded quality attributes by the choices a supplier makes from design through component selection and process specification and control. Because this work dealt with manufactured products, many QFD textbook and training examples are cast in a manufacturing model. Experience shows that the application to software requires more than a copy and paste of a manufacturing model. A number of key lessons have been learned through experience about the potentials and pitfalls of applying the QFD to software development.Experience shows that the application to software requires more than a copy and paste of a manufacturing model. A number of key lessons have been learned through experience about the potentials and pitfalls of applying the QFD to software development. 317

318 QUALITY FUNCTION DEPLOYMENT: QFD QFD: When and How Does It Fit in Software Development? QFD, while highly customized, usually includes a relationship matrix (Figure 1) with a number of attached analysis sections (like Figures 3 and 5).QFD, while highly customized, usually includes a relationship matrix (Figure 1) with a number of attached analysis sections (like Figures 3 and 5). house-of-quality/qfd-when-and-how-does-it-fit- software-development/ 318

319 QUALITY FUNCTION DEPLOYMENT: QFD QFD: When and How Does It Fit in Software Development? QFD, while highly customized, usually includes a relationship matrix (Figure 1) with a number of attached analysis sections (like Figures 3 and 5).QFD, while highly customized, usually includes a relationship matrix (Figure 1) with a number of attached analysis sections (like Figures 3 and 5). 319

320 QUALITY FUNCTION DEPLOYMENT: QFD QFD: When and How Does It Fit in Software Development? QFD, while highly customized, usually includes a relationship matrix (Figure 1) with a number of attached analysis sections (like Figures 3 and 5).QFD, while highly customized, usually includes a relationship matrix (Figure 1) with a number of attached analysis sections (like Figures 3 and 5). 320 Kano Classifications

321 QUALITY FUNCTION DEPLOYMENT: QFD QFD: When and How Does It Fit in Software Development? QFD, while highly customized, usually includes a relationship matrix (Figure 1) with a number of attached analysis sections (like Figures 3 and 5).QFD, while highly customized, usually includes a relationship matrix (Figure 1) with a number of attached analysis sections (like Figures 3 and 5). 321

322 QUALITY FUNCTION DEPLOYMENT: QFD QFD: When and How Does It Fit in Software Development? At its core, QFD has these common features:At its core, QFD has these common features: QFD Inputs and Starting Conditions 1. Each row describes a requirement; or what Dr. Yoji Akao, co- founder of QFD, called demanded quality. This is the voice of a relevant customer. 2. Each column describes a measurable response to the demanded quality – something that the solution provider would propose to drive and measure in order to satisfy requirements. This is the voice of a provider (e.g., design or construction or test), who will endeavor to address the requirements. 3. Each cell asks a team to evaluate a relationship between the intersecting row and column. Here is a place where QFD is especially interesting, and sometimes confusing. Depending on the objective of a particular QFD, and its place in the development cycle, the sense of this evaluation can be quite different. 322

323 QUALITY FUNCTION DEPLOYMENT: QFD At its core, QFD has these common features:…At its core, QFD has these common features:… QFD Outputs 1.An Issues Log. (ie What are the issues?) A team, with different insights into the QFD’s objectives, has a short but meaningful discussion to evaluate each relevant cell.A team, with different insights into the QFD’s objectives, has a short but meaningful discussion to evaluate each relevant cell. This can be more important that the number or symbol that gets posted in the cell.This can be more important that the number or symbol that gets posted in the cell. The Issues Log capturesThe Issues Log captures action items,action items, communication links,communication links, risks and opportunities, etc.risks and opportunities, etc. The act of having this discussion checks and improves a team’s shared understanding about theThe act of having this discussion checks and improves a team’s shared understanding about the requirements,requirements, measures and key issues,measures and key issues, wherever the QFD occurs. 323

324 QUALITY FUNCTION DEPLOYMENT: QFD At its core, QFD has these common features:…At its core, QFD has these common features:… QFD Outputs… 2.The Evaluation Values for Each Relevant Cell. These values document the outcome of discussion, but they are not an end unto themselves.These values document the outcome of discussion, but they are not an end unto themselves. Some companies have moved QFD out of their development process because teams were “majoring in the minors” – spending hours on giant matrices just to get the values all filled in.Some companies have moved QFD out of their development process because teams were “majoring in the minors” – spending hours on giant matrices just to get the values all filled in. 324

325 QUALITY FUNCTION DEPLOYMENT: QFD At its core, QFD has these common features:…At its core, QFD has these common features:… QFD Outputs 3. Column-wise gap analysis (Figure 6). This varies with different QFD tools, but some column analyses that have been found useful in software environments are: a. Technology gaps b. Measurement gaps c. Competitive analysis gaps 325

326 QUALITY FUNCTION DEPLOYMENT: QFD 3. Column-wise gap analysis (Figure 6). This varies with different QFD tools, but some column analyses that have been found useful in software environments are: a. Technology gaps b. Measurement gaps c. Competitive analysis gaps 326

327 QUALITY FUNCTION DEPLOYMENT: QFD At its core, QFD has these common features:…At its core, QFD has these common features:… QFD Outputs… Just those simple basics can give rise to QFDs that take on a unique flavor depending on where and how they are applied.Just those simple basics can give rise to QFDs that take on a unique flavor depending on where and how they are applied. To illustrate, here are two contrasting examples,To illustrate, here are two contrasting examples, the first with the familiar “How important is each measure” thrust, andthe first with the familiar “How important is each measure” thrust, and the second with the objective of improving deployment through detailed design and integration.the second with the objective of improving deployment through detailed design and integration. While the second application of QFD is much less common, it can be one of the most useful in software development, where integration risks are too well known.While the second application of QFD is much less common, it can be one of the most useful in software development, where integration risks are too well known. 327

328 QUALITY FUNCTION DEPLOYMENT: QFD At its core, QFD has these common features:…At its core, QFD has these common features:… QFD Application 1: How Important is Each Measure? This may be the most common QFD use.This may be the most common QFD use. Measures, sometimes considered in connection with their direction of improvement, are evaluated in each cell in terms of “how important would that response to this (row’s) requirement be?”Measures, sometimes considered in connection with their direction of improvement, are evaluated in each cell in terms of “how important would that response to this (row’s) requirement be?” This can help a software development team in a number of ways:This can help a software development team in a number of ways: It checks a team’s shared understanding about what the requirements and measures really mean.It checks a team’s shared understanding about what the requirements and measures really mean. This may sound simple, but the act of having a short discussion about the ways in which each prospective response could relate to each requirement uncovers differences of opinion and perspective across the team.This may sound simple, but the act of having a short discussion about the ways in which each prospective response could relate to each requirement uncovers differences of opinion and perspective across the team. Better for a team to struggle at this early stage to reach some common view of what’s meant by each requirement and measure.Better for a team to struggle at this early stage to reach some common view of what’s meant by each requirement and measure. 328

329 QUALITY FUNCTION DEPLOYMENT: QFD At its core, QFD has these common features:…At its core, QFD has these common features:… QFD Application 1: How Important is Each Measure?... While the requirements should have already been characterized (e.g., Kano classifications) and prioritized before a QFD, the prioritization of measures during this kind of QFD can focus work on solution generation (stimulating extra creativity on the solution aspects connected with the most important measures).While the requirements should have already been characterized (e.g., Kano classifications) and prioritized before a QFD, the prioritization of measures during this kind of QFD can focus work on solution generation (stimulating extra creativity on the solution aspects connected with the most important measures). Prioritized measures suggest focus for measurement systems analysis and test.Prioritized measures suggest focus for measurement systems analysis and test. The most important measures should be done most carefully – using a measurement system that’s been most rigorously built and checked.The most important measures should be done most carefully – using a measurement system that’s been most rigorously built and checked. 329

330 QUALITY FUNCTION DEPLOYMENT: QFD At its core, QFD has these common features:…At its core, QFD has these common features:… QFD Application 1: How Important is Each Measure?... This QFD approach requires clarity at the start about whether or not a solution concept has been selected.This QFD approach requires clarity at the start about whether or not a solution concept has been selected. If applied upstream of a solution concept, success with this method calls for a look-ahead to the number and kind of solution concepts that may be considered.If applied upstream of a solution concept, success with this method calls for a look-ahead to the number and kind of solution concepts that may be considered. If a team sees itself hedging evaluations with “it depends on which solution is selected,” then it probably isn’t a good use of time to step through this QFD.If a team sees itself hedging evaluations with “it depends on which solution is selected,” then it probably isn’t a good use of time to step through this QFD. Alternately, if the evaluations can be done in a solution-free frame, then this QFD can improve understanding and inform solution generation ideas.Alternately, if the evaluations can be done in a solution-free frame, then this QFD can improve understanding and inform solution generation ideas. 330

331 QUALITY FUNCTION DEPLOYMENT: QFD At its core, QFD has these common features:…At its core, QFD has these common features:… QFD Application 1: How Important is Each Measure?... This QFD approach requires clarity at the start about whether or not a solution concept has been selected.This QFD approach requires clarity at the start about whether or not a solution concept has been selected. If applied upstream of a solution concept, success with this method calls for a look-ahead to the number and kind of solution concepts that may be considered.If applied upstream of a solution concept, success with this method calls for a look-ahead to the number and kind of solution concepts that may be considered. If a team sees itself hedging evaluations with “it depends on which solution is selected,” then it probably isn’t a good use of time to step through this QFD.If a team sees itself hedging evaluations with “it depends on which solution is selected,” then it probably isn’t a good use of time to step through this QFD. Alternately, if the evaluations can be done in a solution-free frame, then this QFD can improve understanding and inform solution generation ideas.Alternately, if the evaluations can be done in a solution-free frame, then this QFD can improve understanding and inform solution generation ideas. 331

332 QUALITY FUNCTION DEPLOYMENT: QFD Figure 3 shows a few importance evaluations.Figure 3 shows a few importance evaluations. As mentioned, the discussion about what the measures and requirements mean is often as important as the numeric evaluation scores.As mentioned, the discussion about what the measures and requirements mean is often as important as the numeric evaluation scores. In a situation where there is already good clarity and shared understanding on the requirements and the measures – and especially if prioritization work has been done already on a per requirement and measure basis, this form of QFD is of questionable value.In a situation where there is already good clarity and shared understanding on the requirements and the measures – and especially if prioritization work has been done already on a per requirement and measure basis, this form of QFD is of questionable value. 332 Before committing the time and resources to this grid, teams should look at what they stand to learn and understand how the results will be used. (The grid can be much larger in a real project.) Before committing the time and resources to this grid, teams should look at what they stand to learn and understand how the results will be used. (The grid can be much larger in a real project.)

333 QUALITY FUNCTION DEPLOYMENT: QFD QFD Application 2: What Are Design and Integration Risks and Opportunities? In a software project involving more than a few people, after a solution architecture has been selected, individuals and small teams set out to detail the design and construct their parts of the puzzle.In a software project involving more than a few people, after a solution architecture has been selected, individuals and small teams set out to detail the design and construct their parts of the puzzle. While each of these units of work might be optimized enough unto itself, there is always some risk that the system will not integrate as planned.While each of these units of work might be optimized enough unto itself, there is always some risk that the system will not integrate as planned. Interactions among the units may not be considered, or even visible, as part of a sub-team’s focused work.Interactions among the units may not be considered, or even visible, as part of a sub-team’s focused work. QFD can help here, but it calls for a different sense of the cell evaluations than the method described in Application 1.QFD can help here, but it calls for a different sense of the cell evaluations than the method described in Application 1. Figure 4 outlines the sense of this application of QFD.Figure 4 outlines the sense of this application of QFD. 333

334 QUALITY FUNCTION DEPLOYMENT: QFD QFD Application 2: What Are Design and Integration Risks and Opportunities?... Figure 4 outlines the sense of this application of QFD.Figure 4 outlines the sense of this application of QFD. 334

335 QUALITY FUNCTION DEPLOYMENT: QFD QFD Application 2: What Are Design and Integration Risks and Opportunities?... Figure 4 outlines the sense of this application of QFD.Figure 4 outlines the sense of this application of QFD. Each column’s measure and direction of improvement is seen as a design endeavor, about to be launched.Each column’s measure and direction of improvement is seen as a design endeavor, about to be launched. The question to consider in evaluating each cell is: “As we picture that measure being driven, in the context of our selected solution and in our development environment, to what extent do we anticipate: support and leverage (black numbers 1-9 in Figure 5) or risk and potential damaging effects (red numbers 1-9 in Figure 5) to each requirement?”The question to consider in evaluating each cell is: “As we picture that measure being driven, in the context of our selected solution and in our development environment, to what extent do we anticipate: support and leverage (black numbers 1-9 in Figure 5) or risk and potential damaging effects (red numbers 1-9 in Figure 5) to each requirement?” 335

336 QUALITY FUNCTION DEPLOYMENT: QFD QFD Application 2: What Are Design and Integration Risks and Opportunities?... The question to consider in evaluating each cell is: “As we picture that measure being driven, in the context of our selected solution and in our development environment, to what extent do we anticipate: support and leverage (black numbers 1-9 in Figure 5) or risk and potential damaging effects (red numbers 1-9 in Figure 5) to each requirement?”The question to consider in evaluating each cell is: “As we picture that measure being driven, in the context of our selected solution and in our development environment, to what extent do we anticipate: support and leverage (black numbers 1-9 in Figure 5) or risk and potential damaging effects (red numbers 1-9 in Figure 5) to each requirement?” 336

337 QUALITY FUNCTION DEPLOYMENT: QFD QFD Application 2: What Are Design and Integration Risks and Opportunities?... Figure 5 shows a few evaluations to illustrate how this can play out.Figure 5 shows a few evaluations to illustrate how this can play out. In this example a firmware team (working on low-level robotics) and an applications team (developing the system level applications that ride the robotics) are checking their integration risks and opportunities early in design.In this example a firmware team (working on low-level robotics) and an applications team (developing the system level applications that ride the robotics) are checking their integration risks and opportunities early in design. The pink sections show that there are places where the measures being driven by one team may impact requirements that seem to be the purview of the other.The pink sections show that there are places where the measures being driven by one team may impact requirements that seem to be the purview of the other. 337

338 QUALITY FUNCTION DEPLOYMENT: QFD QFD Application 2: What Are Design and Integration Risks and Opportunities?... The highlighted “9″ in Row 10 shows that ‘the plan for driving up database interface extensibility’ (that column’s measure in light of the solution concept) stands to significantly help the ability of “technicians to diagnose and fix problems remotely” (the row’s requirement). Flagging this now can help put in place the cross-team communication, results measurement and review attention to assure that this opportunity is realized.The highlighted “9″ in Row 10 shows that ‘the plan for driving up database interface extensibility’ (that column’s measure in light of the solution concept) stands to significantly help the ability of “technicians to diagnose and fix problems remotely” (the row’s requirement). Flagging this now can help put in place the cross-team communication, results measurement and review attention to assure that this opportunity is realized. 338

339 QUALITY FUNCTION DEPLOYMENT: QFD QFD Application 2: What Are Design and Integration Risks and Opportunities?... The highlighted “-9″ in Row 4 highlights a strong risk that the plan for driving up tracking speed (the row’s measure in light of the solution concept) may interfere with or compromise the application team’s ability to optimize routing. Flagging this now can put proper cautions, lines of communication and review attention in place to be sure the risk is minimized and managed.The highlighted “-9″ in Row 4 highlights a strong risk that the plan for driving up tracking speed (the row’s measure in light of the solution concept) may interfere with or compromise the application team’s ability to optimize routing. Flagging this now can put proper cautions, lines of communication and review attention in place to be sure the risk is minimized and managed. This QFD can be seen as a mental experiment to anticipate and leverage opportunity and to reduce and manage integration risk.This QFD can be seen as a mental experiment to anticipate and leverage opportunity and to reduce and manage integration risk. Done well, it can make it a much surer bet that when all the individuals and sub-teams come back together, things will integrate and play as planned.Done well, it can make it a much surer bet that when all the individuals and sub-teams come back together, things will integrate and play as planned. 339

340 QUALITY FUNCTION DEPLOYMENT: QFD QFD Application 2: What Are Design and Integration Risks and Opportunities?... The Value of Gap Analysis In each of the kinds of QFD outlined here, and many others, it is useful to pursue the column-wise gap analysis (Figure 6 or Room 9 in Figure 1).In each of the kinds of QFD outlined here, and many others, it is useful to pursue the column-wise gap analysis (Figure 6 or Room 9 in Figure 1). A team assessing technology gaps is better prepared to overcome them or live with known limitations.A team assessing technology gaps is better prepared to overcome them or live with known limitations. Measurement gaps are common in software environments, and worth bringing to the surface early.Measurement gaps are common in software environments, and worth bringing to the surface early. It is useful to understand competitive gaps in all areas of product development.It is useful to understand competitive gaps in all areas of product development. 340

341 QUALITY FUNCTION DEPLOYMENT: QFD Quality function deployment (QFD) is a “methodQuality function deployment (QFD) is a “method to transform user demands into design quality,to transform user demands into design quality, to deploy the functions forming quality,to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process.”, as described by Dr. Yoji Akao, who originally developed QFD in Japan in 1966, when the author combined his work in quality assurance and quality control points with function deployment used in value engineering.and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process.”, as described by Dr. Yoji Akao, who originally developed QFD in Japan in 1966, when the author combined his work in quality assurance and quality control points with function deployment used in value engineering. QFD is designed to help planners focus on:-QFD is designed to help planners focus on:- characteristics of a new or existing product or service from the viewpoints of market segments, company, or technology- development needs.characteristics of a new or existing product or service from the viewpoints of market segments, company, or technology- development needs. The technique yields charts and matrices.The technique yields charts and matrices. 341

342 QUALITY FUNCTION DEPLOYMENT: QFD QFD helps transform customer needs (the voice of the customer [VOC]) into engineering characteristics (and appropriate test methods) for a product or service, prioritizing each product or service characteristic while simultaneously setting development targets for product or service.QFD helps transform customer needs (the voice of the customer [VOC]) into engineering characteristics (and appropriate test methods) for a product or service, prioritizing each product or service characteristic while simultaneously setting development targets for product or service. 342

343 QUALITY FUNCTION DEPLOYMENT: QFD Quality Function Deployment Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software.Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software. QFD “concentrates on maximizing customer satisfaction from the software engineering process”.QFD “concentrates on maximizing customer satisfaction from the software engineering process”. To accomplish this, QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process.To accomplish this, QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process. QFD identifies three types of requirements :QFD identifies three types of requirements : 343

344 QUALITY FUNCTION DEPLOYMENT: QFD Quality Function Deployment… QFD identifies three types of requirements :QFD identifies three types of requirements : 1.Normal requirements. The objectives and goals that are stated for a product or system during meetings with the customer. If these requirements are present, the customer is satisfied. Examples of normal requirements might be requested types of graphical displays, specific system functions, and defined levels of performance. 2.Expected Requirements. These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction. Examples of expected requirements are: ease of human/machine interaction, overall operational correctness and reliability, and ease of software installation. 3.Exciting Requirements. These features go beyond the customer’s expectations and prove to be very satisfying when present. For example, software for a new mobile phone comes with standard features, but is coupled with a set of unexpected capabilities (e.g., multitouch screen, visual voice mail) that delight every user of the product. 344

345 QUALITY FUNCTION DEPLOYMENT: QFD Quality Function Deployment… Although QFD concepts can be applied across the entire software process, specific QFD techniques are applicable to the requirements elicitation activity.Although QFD concepts can be applied across the entire software process, specific QFD techniques are applicable to the requirements elicitation activity. QFD uses customer interviews and observation, surveys, and examination of historical data (e.g., problem reports) as raw data for the requirements gathering activity.QFD uses customer interviews and observation, surveys, and examination of historical data (e.g., problem reports) as raw data for the requirements gathering activity. These data are then translated into a table of requirements — called the customer voice table — that is reviewed with the customer and other stakeholders.These data are then translated into a table of requirements — called the customer voice table — that is reviewed with the customer and other stakeholders. A variety of diagrams, matrices, and evaluation methods are then used to extract expected requirements and to attempt to derive exciting requirements.A variety of diagrams, matrices, and evaluation methods are then used to extract expected requirements and to attempt to derive exciting requirements. 345

346 QUALITY FUNCTION DEPLOYMENT: QFD Introduction In the world of business and industry, every organization has customers.In the world of business and industry, every organization has customers. Some have only internal customers, some just external customers, and some have both.Some have only internal customers, some just external customers, and some have both. When you are working to determine what you need to accomplish to satisfy or even delight your customers, then the tool of choice is quality function deployment or QFD.When you are working to determine what you need to accomplish to satisfy or even delight your customers, then the tool of choice is quality function deployment or QFD. 346

347 QUALITY FUNCTION DEPLOYMENT: QFD Background Quality professionals refer to QFD by many names, including matrix product planning, decision matrices, and customer-driven engineering.Quality professionals refer to QFD by many names, including matrix product planning, decision matrices, and customer-driven engineering. Whatever you call it,Whatever you call it, QFD is a focused methodology for carefully listening to the voice of the customer andQFD is a focused methodology for carefully listening to the voice of the customer and then effectively responding to those needs and expectations.then effectively responding to those needs and expectations. First developed in Japan in the late 1960s as a form of cause-and- effect analysis, QFD was brought to the United States in the early 1980s.First developed in Japan in the late 1960s as a form of cause-and- effect analysis, QFD was brought to the United States in the early 1980s. It gained its early popularity as a result of numerous successes in the automotive industry.It gained its early popularity as a result of numerous successes in the automotive industry. 347

348 QUALITY FUNCTION DEPLOYMENT: QFD Methodology In QFD, quality is a measure of customer satisfaction with a product or a service.In QFD, quality is a measure of customer satisfaction with a product or a service. QFD is a structured method that uses the seven management and planning tools to identify and prioritize customers’ expectations quickly and effectively.QFD is a structured method that uses the seven management and planning tools to identify and prioritize customers’ expectations quickly and effectively. Beginning with the initial matrix, commonly termed the house of quality, depicted in Figure 1, the QFD methodology focuses on the most important product or service attributes or qualities.Beginning with the initial matrix, commonly termed the house of quality, depicted in Figure 1, the QFD methodology focuses on the most important product or service attributes or qualities. These are composed of customer wows, wants, and musts. (See the Kano model of customer perception versus customer reality.)These are composed of customer wows, wants, and musts. (See the Kano model of customer perception versus customer reality.) 348

349 QUALITY FUNCTION DEPLOYMENT: QFD Methodology… Once you have prioritized the attributes and qualities, QFD deploys them to the appropriate organizational function for action, as shown in Figure 2.Once you have prioritized the attributes and qualities, QFD deploys them to the appropriate organizational function for action, as shown in Figure 2. Thus, QFD is the deployment of customer-driven qualities to the responsible functions of an organization.Thus, QFD is the deployment of customer-driven qualities to the responsible functions of an organization. 349

350 QUALITY FUNCTION DEPLOYMENT: QFD Methodology… Once you have prioritized the attributes and qualities, QFD deploys them to the appropriate organizational function for action, as shown in Figure 2.Once you have prioritized the attributes and qualities, QFD deploys them to the appropriate organizational function for action, as shown in Figure 2. Thus, QFD is the deployment of customer-driven qualities to the responsible functions of an organization.Thus, QFD is the deployment of customer-driven qualities to the responsible functions of an organization. 350

351 QUALITY FUNCTION DEPLOYMENT: QFD Methodology… Many QFD practitioners claim that using QFD has enabled them to reduce their product and service development cycle times by as much as 75 percent with equally impressive improvements in measured customer satisfaction.Many QFD practitioners claim that using QFD has enabled them to reduce their product and service development cycle times by as much as 75 percent with equally impressive improvements in measured customer satisfaction. 351

352 352

353 QUALITY FUNCTION DEPLOYMENT: QFD Quality Function Deployment (QFD) is a systematic process for motivating a business to focus on its customers.Quality Function Deployment (QFD) is a systematic process for motivating a business to focus on its customers. It is used by cross-functional teams to identify and resolve issues involved in providing products, processes, services and strategies which will more than satisfy their customers.It is used by cross-functional teams to identify and resolve issues involved in providing products, processes, services and strategies which will more than satisfy their customers. A prerequisite to QFD is Market Research. This is the process of understanding what the customer wants, how important these benefits are, and how well different providers of products that address these benefits are perceived to perform. This is a prerequisite to QFD because it is impossible to consistently provide products which will attract customers unless you have a very good understanding of what they want.A prerequisite to QFD is Market Research. This is the process of understanding what the customer wants, how important these benefits are, and how well different providers of products that address these benefits are perceived to perform. This is a prerequisite to QFD because it is impossible to consistently provide products which will attract customers unless you have a very good understanding of what they want. When completed it resembles a house structure and is often referred to as House of Quality.When completed it resembles a house structure and is often referred to as House of Quality. 353

354 QUALITY FUNCTION DEPLOYMENT: QFD… The House is divided into several rooms. Typically you haveThe House is divided into several rooms. Typically you have customer requirements,customer requirements, design considerations anddesign considerations and design alternativesdesign alternatives in a 3 dimensional matrix to which you can assign weighted scores based on market research information collected. Quality Function Deployment (QFD) is a methodology for taking the Voice of the Customer and using that information to drive aspects of product development.Quality Function Deployment (QFD) is a methodology for taking the Voice of the Customer and using that information to drive aspects of product development. Cross functional teams participate in the process that consists of matrices that analyze data sets according to the objective of the QFD process.Cross functional teams participate in the process that consists of matrices that analyze data sets according to the objective of the QFD process. A typical QFD process involves a four phase approach. This approach has been made popular by the American Supplies Institute.A typical QFD process involves a four phase approach. This approach has been made popular by the American Supplies Institute. 354

355 QUALITY FUNCTION DEPLOYMENT: QFD… QFD is not just the House of Quality–matrix 1. It involves much more and matrices that are connected together using priority ratings from the previous matrix.QFD is not just the House of Quality–matrix 1. It involves much more and matrices that are connected together using priority ratings from the previous matrix. Quality Function Deployment (QFD) is a structured approach to defining customer needs or requirements and translating them into specific plans to produce products to meet those needs.Quality Function Deployment (QFD) is a structured approach to defining customer needs or requirements and translating them into specific plans to produce products to meet those needs. The “voice of the customer” is the term to describe these stated and unstated customer needs or requirements.The “voice of the customer” is the term to describe these stated and unstated customer needs or requirements. The voice of the customer is captured in a variety of ways:The voice of the customer is captured in a variety of ways: 1.direct discussion or interviews, 2.surveys, 3.focus groups, 4.customer specifications, 5.observation, 6.warranty data, 7.field reports, etc. 355

356 QUALITY FUNCTION DEPLOYMENT: QFD… This understanding of the customer needs is then summarized in a product planning matrix or “house of quality”.This understanding of the customer needs is then summarized in a product planning matrix or “house of quality”. These matrices are used to translate higher level “whats” or needs into lower level “hows” – product requirements or technical characteristics to satisfy these needs.These matrices are used to translate higher level “whats” or needs into lower level “hows” – product requirements or technical characteristics to satisfy these needs. 356

357 357 S/W DESIGN CONCEPTS* Note: * indicates “topic as per syllabus”

358 358 TRANSLATING THE ANALYSIS MODEL INTO A SOFTWARE DESIGN

359 359 TRANSLATING THE ANALYSIS MODEL INTO A SOFTWARE DESIGN

360 360 TRANSLATING THE ANALYSIS MODEL INTO A SOFTWARE DESIGN

361 361 S/W DESIGN CONCEPTS* Introduction. 1.Software development is a creative activity. 2.There is an inherent tendency in any creative process to be:- – neither precise nor accurate, but rather to follow the inspiration of the moment in an unstructured manner. 3.Rigor(Strict accuracy), on the other hand, is a necessary complement to creativity in every engineering activity.

362 362 S/W DESIGN CONCEPTS*… Introduction… 4.It is only through a rigorous approach that we can produce more reliable products, control their costs, and increase our confidence in their reliability. 5.Rigor does not need to constrain creativity. 6.Rather, it enhances creativity by improving the engineer's confidence in creative results, once they are critically analyzed in the light of a rigorous assessment.

363 363 S/W DESIGN CONCEPTS*… Introduction… 7.A set of fundamental software design concepts has evolved over the past four decades. 8.Each concept provides the software designer with a foundation from which more sophisticated design methods can be applied. 9.Each helps the software engineer to answer the following questions: i.What criteria can be used to partition software into individual components? ii.How is function or data structure detail separated from a conceptual representation of the software? iii.What uniform criteria define the technical quality of a software design ?

364 364 DESIGN CRITERIA 1.Structure. A design should exhibit an architectural structure that: has been created using recognizable design patterns (e.g. Object-oriented design patterns ). 2.Modularity. A design should be modular. 3.Documentation. – A good design always comes with a set of well-written documents. – An excellent design without good quality documentation becomes a poor design. 4.Discreteness. – A good design separates data, procedures (functions), and timing considerations to the extent possible. 5.Testability. In a good design, every requirement is testable. 6.Representation. – A good design should be easily communicated to all interested parties through appropriate abstractions and representations. 7.Reusability. – A good design should be repeatable or reusable.

365 365 S/W DESIGN CONCEPTS Introduction. M.A. Jackson once said, "The beginning of wisdom for a software engineer is to recognize the difference between getting a program to work, and getting it right."

366 366 S/W DESIGN CONCEPTS*

367 367 S/W DESIGN CONCEPTS* (a general notion, a theme) Meaning of Concept 1. A general notion or idea; conception. 2. An idea of something formed by mentally combining all its characteristics or particulars; a construct. 3. A directly conceived or intuited object of thought. 4. A theme or image, esp. as embodied in the design or execution of something.

368 368 S/W DESIGN CONCEPTS* (a general notion, a theme) Meaning of Principle A principle is a law or rule that – has to be, or usually – is to be followed, or – can be desirably followed, or – is an inevitable consequence of something, such as the laws observed in nature or the way that a system is constructed. The principles of such a system are understood by its users as the essential characteristics of the system, or reflecting system's designed purpose, and the effective operation or use of which would be impossible if any one of the principles was to be ignored.

369 S/W DESIGN CONCEPTS* (a general notion, a theme) A set of fundamental software design concepts has evolved over the history of software engineering. Although the degree of interest in each concept has varied over the years, each has stood the test of time. Each concept provides the software designer with a foundation from which more sophisticated design methods can be applied. Each helps you answer the following questions: – What criteria can be used to partition software into individual components? – How is function or data structure detail separated from a conceptual representation of the software? – What uniform criteria define the technical quality of a software design? 369

370 S/W DESIGN CONCEPTS* (a general notion, a theme) M. A. Jackson once said: “The beginning of wisdom for a software engineer is to recognize the difference between getting a program to work, and getting it right.” Fundamental software design concepts provide the necessary framework for “getting it right.” 370

371 371 S/W DESIGN CONCEPTS* (a general notion, a theme) Abstraction Abstraction When you consider a modular solution to any problem, many levels of abstraction can be posed. When you consider a modular solution to any problem, many levels of abstraction can be posed. At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided. At lower levels of abstraction, a more detailed description of the solution is provided. Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution. Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution. Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. As different levels of abstraction are developed, you work to create both procedural and data abstractions. As different levels of abstraction are developed, you work to create both procedural and data abstractions.

372 372 S/W DESIGN CONCEPTS* (a general notion, a theme) Abstraction Abstraction When you consider a modular solution to any problem, many levels of abstraction can be posed. When you consider a modular solution to any problem, many levels of abstraction can be posed. At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided. At lower levels of abstraction, a more detailed description of the solution is provided. Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution. Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution. Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. As different levels of abstraction are developed, you work to create both procedural and data abstractions. As different levels of abstraction are developed, you work to create both procedural and data abstractions. A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed. An example of a procedural implies these functions, but specific details are suppressed. An example of a procedural abstraction would be the word open for a door. Open implies a long sequence abstraction would be the word open for a door. Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving door, etc.).5 pull door, step away from moving door, etc.).5 A data abstraction is a named collection of data that describes a data object. In A data abstraction is a named collection of data that describes a data object. In the context of the procedural abstraction open, we can define a data abstraction the context of the procedural abstraction open, we can define a data abstraction called door. Like any data object, the data abstraction for door would encompass called door. Like any data object, the data abstraction for door would encompass a set of attributes that describe the door (e.g., door type, swing direction, opening a set of attributes that describe the door (e.g., door type, swing direction, opening mechanism, weight, dimensions). It follows that the procedural abstraction open mechanism, weight, dimensions). It follows that the procedural abstraction open would make use of information contained in the attributes of the data abstraction would make use of information contained in the attributes of the data abstraction door. door Architecture Architecture Software architecture alludes to “the overall structure of the software and the ways Software architecture alludes to “the overall structure of the software and the ways in which that structure provides conceptual integrity for a system” [Sha95a]. In its in which that structure provides conceptual integrity for a system” [Sha95a]. In its simplest form, architecture is the structure or organization of program components simplest form, architecture is the structure or organization of program components (modules), the manner in which these components interact, and the structure of data (modules), the manner in which these components interact, and the structure of data that are used by the components. In a broader sense, however, components can be that are used by the components. In a broader sense, however, components can be generalized to represent major system elements and their interactions. generalized to represent major system elements and their interactions. One goal of software design is to derive an architectural rendering of a system. One goal of software design is to derive an architectural rendering of a system. This rendering serves as a framework from which more detailed design activities are This rendering serves as a framework from which more detailed design activities are conducted. A set of architectural patterns enables a software engineer to solve conducted. A set of architectural patterns enables a software engineer to solve common design problems. common design problems. CHAPTER 8 DESIGN CONCEPTS 223 CHAPTER 8 DESIGN CONCEPTS 223 uote: uote: Shaw and Garlan [Sha95a] describe a set of properties that should be specified as Shaw and Garlan [Sha95a] describe a set of properties that should be specified as part of an architectural design: part of an architectural design: Structural properties. This aspect of the architectural design representation defines Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects, filters) and the manner in which the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods. via the invocation of methods. Extra-functional properties. The architectural design description should address Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. security, adaptability, and other system characteristics. Families of related systems. The architectural design should draw upon repeatable Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks. essence, the design should have the ability to reuse architectural building blocks. Given the specification of these properties, the architectural design can be represented Given the specification of these properties, the architectural design can be represented using one or more of a number of different models [Gar95]. Structural models using one or more of a number of different models [Gar95]. Structural models represent architecture as an organized collection of program components. represent architecture as an organized collection of program components. Framework models increase the level of design abstraction by attempting to identify Framework models increase the level of design abstraction by attempting to identify repeatable architectural design frameworks that are encountered in similar types of repeatable architectural design frameworks that are encountered in similar types of applications. Dynamic models address the behavioral aspects of the program architecture, applications. Dynamic models address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function indicating how the structure or system configuration may change as a function of external events. Process models focus on the design of the business or of external events. Process models focus on the design of the business or technical process that the system must accommodate. Finally, functional models can technical process that the system must accommodate. Finally, functional models can be used to represent the functional hierarchy of a system. be used to represent the functional hierarchy of a system. A number of different architectural description languages (ADLs) have been developed A number of different architectural description languages (ADLs) have been developed to represent these models [Sha95b]. Although many different ADLs have been to represent these models [Sha95b]. Although many different ADLs have been proposed, the majority provide mechanisms for describing system components and proposed, the majority provide mechanisms for describing system components and the manner in which they are connected to one another. the manner in which they are connected to one another. You should note that there is some debate about the role of architecture in design. You should note that there is some debate about the role of architecture in design. Some researchers argue that the derivation of software architecture should be separated Some researchers argue that the derivation of software architecture should be separated from design and occurs between requirements engineering actions and more from design and occurs between requirements engineering actions and more conventional design actions. Others believe that the derivation of architecture is an conventional design actions. Others believe that the derivation of architecture is an integral part of the design process. The manner in which software architecture is integral part of the design process. The manner in which software architecture is characterized and its role in design are discussed in Chapter 9. characterized and its role in design are discussed in Chapter Patterns Patterns Brad Appleton defines a design pattern in the following manner: “A pattern is a Brad Appleton defines a design pattern in the following manner: “A pattern is a named nugget of insight which conveys the essence of a proven solution to a recurring named nugget of insight which conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns” [App00]. Stated problem within a certain context amidst competing concerns” [App00]. Stated in another way, a design pattern describes a design structure that solves a particular in another way, a design pattern describes a design structure that solves a particular design problem within a specific context and amid “forces” that may have an impact design problem within a specific context and amid “forces” that may have an impact on the manner in which the pattern is applied and used. on the manner in which the pattern is applied and used. The intent of each design pattern is to provide a description that enables a The intent of each design pattern is to provide a description that enables a designer to determine (1) whether the pattern is applicable to the current work, designer to determine (1) whether the pattern is applicable to the current work, (2) whether the pattern can be reused (hence, saving design time), and (3) whether (2) whether the pattern can be reused (hence, saving design time), and (3) whether the pattern can serve as a guide for developing a similar, but functionally or structurally the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern. Design patterns are discussed in detail in Chapter 12. different pattern. Design patterns are discussed in detail in Chapter Separation of Concerns Separation of Concerns Separation of concerns is a design concept [Dij82] that suggests that any complex Separation of concerns is a design concept [Dij82] that suggests that any complex problem can be more easily handled if it is subdivided into pieces that can each be problem can be more easily handled if it is subdivided into pieces that can each be solved and/or optimized independently. A concern is a feature or behavior that is solved and/or optimized independently. A concern is a feature or behavior that is specified as part of the requirements model for the software. By separating concerns specified as part of the requirements model for the software. By separating concerns into smaller, and therefore more manageable pieces, a problem takes less effort and into smaller, and therefore more manageable pieces, a problem takes less effort and time to solve. time to solve. For two problems, p1 and p2, if the perceived complexity of p1 is greater than the For two problems, p1 and p2, if the perceived complexity of p1 is greater than the perceived complexity of p2, it follows that the effort required to solve p1 is greater perceived complexity of p2, it follows that the effort required to solve p1 is greater than the effort required to solve p2. As a general case, this result is intuitively obvious. than the effort required to solve p2. As a general case, this result is intuitively obvious. It does take more time to solve a difficult problem. It does take more time to solve a difficult problem. It also follows that the perceived complexity of two problems when they are combined It also follows that the perceived complexity of two problems when they are combined is often greater than the sum of the perceived complexity when each is taken is often greater than the sum of the perceived complexity when each is taken separately. This leads to a divide-and-conquer strategy—it’s easier to solve a complex separately. This leads to a divide-and-conquer strategy—it’s easier to solve a complex problem when you break it into manageable pieces. This has important implications problem when you break it into manageable pieces. This has important implications with regard to software modularity. with regard to software modularity. Separation of concerns is manifested in other related design concepts: modularity, Separation of concerns is manifested in other related design concepts: modularity, aspects, functional independence, and refinement. Each will be discussed in the aspects, functional independence, and refinement. Each will be discussed in the subsections that follow. subsections that follow Modularity Modularity Modularity is the most common manifestation of separation of concerns. Software Modularity is the most common manifestation of separation of concerns. Software is divided into separately named and addressable components, sometimes called is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements. modules, that are integrated to satisfy problem requirements. It has been stated that “modularity is the single attribute of software that allows a It has been stated that “modularity is the single attribute of software that allows a program to be intellectually manageable” [Mye78]. Monolithic software (i.e., a large program to be intellectually manageable” [Mye78]. Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a software engineer. program composed of a single module) cannot be easily grasped by a software engineer. The number of control paths, span of reference, number of variables, and overall The number of control paths, span of reference, number of variables, and overall complexity would make understanding close to impossible. In almost all complexity would make understanding close to impossible. In almost all instances, you should break the design into many modules, hoping to make understanding instances, you should break the design into many modules, hoping to make understanding easier and, as a consequence, reduce the cost required to build the software. easier and, as a consequence, reduce the cost required to build the software. Recalling my discussion of separation of concerns, it is possible to conclude that Recalling my discussion of separation of concerns, it is possible to conclude that if you subdivide software indefinitely the effort required to develop it will become if you subdivide software indefinitely the effort required to develop it will become negligibly small! Unfortunately, other forces come into play, causing this conclusion negligibly small! Unfortunately, other forces come into play, causing this conclusion to be (sadly) invalid. Referring to Figure 8.2, the effort (cost) to develop an individual to be (sadly) invalid. Referring to Figure 8.2, the effort (cost) to develop an individual software module does decrease as the total number of modules increases. Given the software module does decrease as the total number of modules increases. Given the same set of requirements, more modules means smaller individual size. However, as same set of requirements, more modules means smaller individual size. However, as the number of modules grows, the effort (cost) associated with integrating the modules the number of modules grows, the effort (cost) associated with integrating the modules also grows. These characteristics lead to a total cost or effort curve shown in the also grows. These characteristics lead to a total cost or effort curve shown in the figure. There is a number, M, of modules that would result in minimum development figure. There is a number, M, of modules that would result in minimum development cost, but we do not have the necessary sophistication to predict M with assurance. cost, but we do not have the necessary sophistication to predict M with assurance. The curves shown in Figure 8.2 do provide useful qualitative guidance when modularity The curves shown in Figure 8.2 do provide useful qualitative guidance when modularity is considered. You should modularize, but care should be taken to stay in the is considered. You should modularize, but care should be taken to stay in the vicinity of M. Undermodularity or overmodularity should be avoided. But how do you vicinity of M. Undermodularity or overmodularity should be avoided. But how do you know the vicinity of M? How modular should you make software? The answers to know the vicinity of M? How modular should you make software? The answers to these questions require an understanding of other design concepts considered later these questions require an understanding of other design concepts considered later in this chapter. in this chapter. You modularize a design (and the resulting program) so that development can be You modularize a design (and the resulting program) so that development can be more easily planned; software increments can be defined and delivered; changes can more easily planned; software increments can be defined and delivered; changes can be more easily accommodated; testing and debugging can be conducted more efficiently, be more easily accommodated; testing and debugging can be conducted more efficiently, and long-term maintenance can be conducted without serious side effects. and long-term maintenance can be conducted without serious side effects Information Hiding Information Hiding The concept of modularity leads you to a fundamental question: “How do I decompose The concept of modularity leads you to a fundamental question: “How do I decompose a software solution to obtain the best set of modules?” The principle of information a software solution to obtain the best set of modules?” The principle of information hiding [Par72] suggests that modules be “characterized by design decisions hiding [Par72] suggests that modules be “characterized by design decisions that (each) hides from all others.” In other words, modules should be specified and that (each) hides from all others.” In other words, modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information. to other modules that have no need for such information. Hiding implies that effective modularity can be achieved by defining a set of independent Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary modules that communicate with one another only that information necessary to achieve software function. Abstraction helps to define the procedural (or to achieve software function. Abstraction helps to define the procedural (or informational) entities that make up the software. Hiding defines and enforces access informational) entities that make up the software. Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure constraints to both procedural detail within a module and any local data structure used by the module [Ros75]. used by the module [Ros75]. The use of information hiding as a design criterion for modular systems provides The use of information hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later during the greatest benefits when modifications are required during testing and later during software maintenance. Because most data and procedural detail are hidden from software maintenance. Because most data and procedural detail are hidden from other parts of the software, inadvertent errors introduced during modification are other parts of the software, inadvertent errors introduced during modification are less likely to propagate to other locations within the software. less likely to propagate to other locations within the software Functional Independence Functional Independence The concept of functional independence is a direct outgrowth of separation of concerns, The concept of functional independence is a direct outgrowth of separation of concerns, modularity, and the concepts of abstraction and information hiding. In landmark modularity, and the concepts of abstraction and information hiding. In landmark papers on software design, Wirth [Wir71] and Parnas [Par72] allude to papers on software design, Wirth [Wir71] and Parnas [Par72] allude to refinement techniques that enhance module independence. Later work by Stevens, refinement techniques that enhance module independence. Later work by Stevens, Myers, and Constantine [Ste74] solidified the concept. Myers, and Constantine [Ste74] solidified the concept. Functional independence is achieved by developing modules with “singleminded” Functional independence is achieved by developing modules with “singleminded” function and an “aversion” to excessive interaction with other modules. function and an “aversion” to excessive interaction with other modules. Stated another way, you should design software so that each module addresses a Stated another way, you should design software so that each module addresses a specific subset of requirements and has a simple interface when viewed from other specific subset of requirements and has a simple interface when viewed from other parts of the program structure. It is fair to ask why independence is important. parts of the program structure. It is fair to ask why independence is important. Software with effective modularity, that is, independent modules, is easier to develop Software with effective modularity, that is, independent modules, is easier to develop because function can be compartmentalized and interfaces are simplified because function can be compartmentalized and interfaces are simplified (consider the ramifications when development is conducted by a team). Independent (consider the ramifications when development is conducted by a team). Independent modules are easier to maintain (and test) because secondary effects caused by design modules are easier to maintain (and test) because secondary effects caused by design or code modification are limited, error propagation is reduced, and reusable or code modification are limited, error propagation is reduced, and reusable modules are possible. To summarize, functional independence is a key to good design, modules are possible. To summarize, functional independence is a key to good design, and design is the key to software quality. and design is the key to software quality. Independence is assessed using two qualitative criteria: cohesion and coupling. Independence is assessed using two qualitative criteria: cohesion and coupling. Cohesion is an indication of the relative functional strength of a module. Coupling is Cohesion is an indication of the relative functional strength of a module. Coupling is an indication of the relative interdependence among modules. an indication of the relative interdependence among modules. Cohesion is a natural extension of the information-hiding concept described in Cohesion is a natural extension of the information-hiding concept described in Section A cohesive module performs a single task, requiring little interaction Section A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing. Although you should always strive for high cohesion should (ideally) do just one thing. Although you should always strive for high cohesion (i.e., single-mindedness), it is often necessary and advisable to have a (i.e., single-mindedness), it is often necessary and advisable to have a software component perform multiple functions. However, “schizophrenic” components software component perform multiple functions. However, “schizophrenic” components (modules that perform many unrelated functions) are to be avoided if a good (modules that perform many unrelated functions) are to be avoided if a good design is to be achieved. design is to be achieved. Coupling is an indication of interconnection among modules in a software structure. Coupling is an indication of interconnection among modules in a software structure. Coupling depends on the interface complexity between modules, the point at Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface. which entry or reference is made to a module, and what data pass across the interface. In software design, you should strive for the lowest possible coupling. Simple In software design, you should strive for the lowest possible coupling. Simple connectivity among modules results in software that is easier to understand and less connectivity among modules results in software that is easier to understand and less prone to a “ripple effect” [Ste74], caused when errors occur at one location and propagate prone to a “ripple effect” [Ste74], caused when errors occur at one location and propagate throughout a system. throughout a system Refinement Refinement Stepwise refinement is a top-down design strategy originally proposed by Niklaus Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth [Wir71]. A program is developed by successively refining levels of procedural Wirth [Wir71]. A program is developed by successively refining levels of procedural detail. A hierarchy is developed by decomposing a macroscopic statement of function detail. A hierarchy is developed by decomposing a macroscopic statement of function (a procedural abstraction) in a stepwise fashion until programming language (a procedural abstraction) in a stepwise fashion until programming language statements are reached. statements are reached. Refinement is actually a process of elaboration. You begin with a statement of Refinement is actually a process of elaboration. You begin with a statement of function (or description of information) that is defined at a high level of abstraction. function (or description of information) that is defined at a high level of abstraction. That is, the statement describes function or information conceptually but provides That is, the statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure no information about the internal workings of the function or the internal structure of the information. You then elaborate on the original statement, providing more and of the information. You then elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs. more detail as each successive refinement (elaboration) occurs. Abstraction and refinement are complementary concepts. Abstraction enables Abstraction and refinement are complementary concepts. Abstraction enables you to specify procedure and data internally but suppress the need for “outsiders” to you to specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details. Refinement helps you to reveal low-level details have knowledge of low-level details. Refinement helps you to reveal low-level details as design progresses. Both concepts allow you to create a complete design as design progresses. Both concepts allow you to create a complete design model as the design evolves. model as the design evolves Aspects Aspects As requirements analysis occurs, a set of “concerns” is uncovered. These concerns As requirements analysis occurs, a set of “concerns” is uncovered. These concerns “include requirements, use cases, features, data structures, quality-of-service issues, “include requirements, use cases, features, data structures, quality-of-service issues, variants, intellectual property boundaries, collaborations, patterns and contracts” variants, intellectual property boundaries, collaborations, patterns and contracts” [AOS07]. Ideally, a requirements model can be organized in a way that allows you to [AOS07]. Ideally, a requirements model can be organized in a way that allows you to isolate each concern (requirement) so that it can be considered independently. In isolate each concern (requirement) so that it can be considered independently. In practice, however, some of these concerns span the entire system and cannot be practice, however, some of these concerns span the entire system and cannot be easily compartmentalized. easily compartmentalized. As design begins, requirements are refined into a modular design representation. As design begins, requirements are refined into a modular design representation. Consider two requirements, A and B. Requirement A crosscuts requirement B “if a Consider two requirements, A and B. Requirement A crosscuts requirement B “if a software decomposition [refinement] has been chosen in which B cannot be satisfied software decomposition [refinement] has been chosen in which B cannot be satisfied without taking A into account” [Ros04]. without taking A into account” [Ros04]. For example, consider two requirements for the SafeHomeAssured.com WebApp. For example, consider two requirements for the SafeHomeAssured.com WebApp. Requirement A is described via the ACS-DCV use case discussed in Chapter 6. A Requirement A is described via the ACS-DCV use case discussed in Chapter 6. A design refinement would focus on those modules that would enable a registered user design refinement would focus on those modules that would enable a registered user to access video from cameras placed throughout a space. Requirement B is a generic to access video from cameras placed throughout a space. Requirement B is a generic security requirement that states that a registered user must be validated prior to using security requirement that states that a registered user must be validated prior to using SafeHomeAssured.com. This requirement is applicable for all functions that are SafeHomeAssured.com. This requirement is applicable for all functions that are available to registered SafeHome users. As design refinement occurs, A* is a design available to registered SafeHome users. As design refinement occurs, A* is a design representation for requirement A and B* is a design representation for requirement B. representation for requirement A and B* is a design representation for requirement B. Therefore, A* and B* are representations of concerns, and B* crosscuts A*. Therefore, A* and B* are representations of concerns, and B* crosscuts A*. An aspect is a representation of a crosscutting concern. Therefore, the design representation, An aspect is a representation of a crosscutting concern. Therefore, the design representation, B*, of the requirement a registered user must be validated prior to using B*, of the requirement a registered user must be validated prior to using SafeHomeAssured.com, is an aspect of the SafeHome WebApp. It is important to SafeHomeAssured.com, is an aspect of the SafeHome WebApp. It is important to identify aspects so that the design can properly accommodate them as refinement identify aspects so that the design can properly accommodate them as refinement and modularization occur. In an ideal context, an aspect is implemented as a separate and modularization occur. In an ideal context, an aspect is implemented as a separate module (component) rather than as software fragments that are “scattered” or module (component) rather than as software fragments that are “scattered” or “tangled” throughout many components [Ban06]. To accomplish this, the design architecture “tangled” throughout many components [Ban06]. To accomplish this, the design architecture should support a mechanism for defining an aspect—a module that enables should support a mechanism for defining an aspect—a module that enables the concern to be implemented across all other concerns that it crosscuts. the concern to be implemented across all other concerns that it crosscuts Refactoring Refactoring An important design activity suggested for many agile methods (Chapter 3), An important design activity suggested for many agile methods (Chapter 3), refactoring is a reorganization technique that simplifies the design (or code) of a refactoring is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior. Fowler [Fow00] defines refactoring component without changing its function or behavior. Fowler [Fow00] defines refactoring in the following manner: “Refactoring is the process of changing a software in the following manner: “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.” yet improves its internal structure.” When software is refactored, the existing design is examined for redundancy, unused When software is refactored, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failure that can be corrected to yield inappropriate data structures, or any other design failure that can be corrected to yield a better design. For example, a first design iteration might yield a component that a better design. For example, a first design iteration might yield a component that exhibits low cohesion (i.e., it performs three functions that have only limited relationship exhibits low cohesion (i.e., it performs three functions that have only limited relationship to one another). After careful consideration, you may decide that the component to one another). After careful consideration, you may decide that the component should be refactored into three separate components, each exhibiting high cohesion. should be refactored into three separate components, each exhibiting high cohesion.