Download to read offline
![13
• closed paradigm—structures a team along a traditional
hierarchy of authority
• random paradigm—structures a team loosely and depends
on individual initiative of the team members
• open paradigm—attempts to structure a team in a manner
that achieves some of the controls associated with the
closed paradigm but also much of the innovation that
occurs when using the random paradigm
• synchronous paradigm—relies on the natural
compartmentalization of a problem and organizes team
members to work on pieces of the problem with little active
communication among themselves
Organizational Paradigms
suggested by Constantine [Con93]](https://image.slidesharecdn.com/chapter1introductionsunorganisedasefinalised-230118152727-19f4c626/85/Chapter-1_Introduction-sunorganisedASE_finalised-pptx-13-320.jpg)
![18
The Project
• Projects get into trouble when …
– Software people don’t understand their customer’s
needs.
– The product scope is poorly defined.
– Changes are managed poorly.
– The chosen technology changes.
– Business needs change [or are ill-defined].
– Deadlines are unrealistic.
– Users are resistant.
– Sponsorship is lost [or was never properly obtained].
– The project team lacks people with appropriate skills.
– Managers [and practitioners] avoid best practices and
lessons learned.](https://image.slidesharecdn.com/chapter1introductionsunorganisedasefinalised-230118152727-19f4c626/85/Chapter-1_Introduction-sunorganisedASE_finalised-pptx-18-320.jpg)
![20
To Get to the Essence of a Project
• Why is the system being developed?
• What will be done?
• When will it be accomplished?
• Who is responsible?
• Where are they organizationally located?
• How will the job be done technically and
managerially?
• How much of each resource (e.g.,
people, software, tools, database) will
be needed?
Barry Boehm [Boe96]](https://image.slidesharecdn.com/chapter1introductionsunorganisedasefinalised-230118152727-19f4c626/85/Chapter-1_Introduction-sunorganisedASE_finalised-pptx-20-320.jpg)
![39
Example: FP Approach
The estimated number of FP is derived:
FPestimated = count-total * [0.65 + 0.01 * S (Fi)]
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total estimated
project cost is $461,000 and estimated effort is 58 person-months.](https://image.slidesharecdn.com/chapter1introductionsunorganisedasefinalised-230118152727-19f4c626/85/Chapter-1_Introduction-sunorganisedASE_finalised-pptx-39-320.jpg)
![68
Earned Value Analysis (EVA)
• Earned value
– is a measure of progress
– enables us to assess the “percent of
completeness” of a project using quantitative
analysis rather than rely on a gut feeling
– “provides accurate and reliable readings of
performance from as early as 15 percent into
the project.” [Fle98]](https://image.slidesharecdn.com/chapter1introductionsunorganisedasefinalised-230118152727-19f4c626/85/Chapter-1_Introduction-sunorganisedASE_finalised-pptx-68-320.jpg)
![70
Computing Earned Value-II
• Next, the value for budgeted cost of work performed (BCWP)
is computed.
– The value for BCWP is the sum of the BCWS values for all
work tasks that have actually been completed by a point in time
on the project schedule.
• “the distinction between the BCWS and the BCWP is that
the former represents the budget of the activities that were
planned to be completed and the latter represents the
budget of the activities that actually were completed.” [Wil99]
• Given values for BCWS, BAC, and BCWP, important
progress indicators can be computed:
• Schedule performance index, SPI = BCWP/BCWS
• Schedule variance, SV = BCWP – BCWS
• SPI is an indication of the efficiency with which the project is
utilizing scheduled resources.](https://image.slidesharecdn.com/chapter1introductionsunorganisedasefinalised-230118152727-19f4c626/85/Chapter-1_Introduction-sunorganisedASE_finalised-pptx-70-320.jpg)
Chapter 1_Introduction sunorganisedASE_finalised.pptx
- 1. These slides aredesigned to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1 Chapter 1 Overview Software Engineering
- 2. 2 What is Software? Softwareis: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information and (3) documentation that describes the operation and use of the programs. Software is developed or engineered, it is not manufactured in the classical sense. Software doesn't "wear out." Although the industry is moving toward component-based construction, most software continues to be custom-built. The IEEE definition: Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).
- 3.
- 4. 4 A Layered Technology SoftwareEngineering a “quality” focus process model methods tools
- 5. 5 Process Framework Activities • Communication •Planning • Modeling – Analysis of requirements – Design • Construction – Code generation – Testing • Deployment
- 6. 6 The Essence ofPractice Polya suggests: 1.Understand the problem (communication and analysis). 2.Plan a solution (modeling and software design). 3.Carry out the plan (code generation). 4.Examine the result for accuracy (testing and quality assurance).
- 7. 7 Hooker’s General Principles 1:The Reason It All Exists 2: KISS (Keep It Simple, Stupid!) 3: Maintain the Vision 4: What You Produce, Others Will Consume 5: Be Open to the Future 6: Plan Ahead for Reuse 7: Think!
- 8. 8 How It allStarts • SafeHome: – Every software project is precipitated by some business need— •the need to correct a defect in an existing application; •the need to the need to adapt a ‘legacy system’ to a changing business environment; •the need to extend the functions and features of an existing application, or •the need to create a new product, service, or system.
- 9. 9 The Four P’s •Project Management Concepts • People — the most important element of a successful project • Product — the software to be built • Process — the set of framework activities and software engineering tasks to get the job done • Project — all work required to make the product a reality Project Management Concepts
- 10. 10 Stakeholders • Senior managerswho define the business issues that often have significant influence on the project. • Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. • Practitioners who deliver the technical skills that are necessary to engineer a product or application. • Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. • End-users who interact with the software once it is released for production use.
- 11. 11 Team Leader The MOIModel – Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability. – Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. – Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.
- 12. 12 Software Teams The followingfactors must be considered when selecting a software project team structure ... the difficulty of the problem to be solved the size of the resultant program(s) in lines of code or function points the time that the team will stay together (team lifetime) the degree to which the problem can be modularized the required quality and reliability of the system to be built the rigidity of the delivery date the degree of sociability (communication) required for the project
- 13. 13 • closed paradigm—structuresa team along a traditional hierarchy of authority • random paradigm—structures a team loosely and depends on individual initiative of the team members • open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm • synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves Organizational Paradigms suggested by Constantine [Con93]
- 14. 14 Avoid Team “Toxicity” •A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed. • High frustration caused by personal, business, or technological factors that cause friction among team members. • “Fragmented or poorly coordinated procedures” or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment. • Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing. • “Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.
- 15. 15 Agile Teams • Teammembers must have trust in one another. • The distribution of skills must be appropriate to the problem. • Mavericks may have to be excluded from the team, if team cohesiveness is to be maintained. • Team is “self-organizing” – An adaptive team structure – Uses elements of Constantine’s random, open, and synchronous paradigms – Significant autonomy
- 16. 16 Problem Decomposition • Sometimescalled partitioning or problem elaboration • Once scope is defined … – It is decomposed into constituent functions – It is decomposed into user-visible data objects or – It is decomposed into a set of problem classes • Decomposition process continues until all functions or problem classes have been
- 17. 17 The Process • Oncea process framework has been established – Consider project characteristics – Determine the degree of rigor required – Define a task set for each software engineering activity • Task set = – Software engineering tasks – Work products – Quality assurance points – Milestones
- 18. 18 The Project • Projectsget into trouble when … – Software people don’t understand their customer’s needs. – The product scope is poorly defined. – Changes are managed poorly. – The chosen technology changes. – Business needs change [or are ill-defined]. – Deadlines are unrealistic. – Users are resistant. – Sponsorship is lost [or was never properly obtained]. – The project team lacks people with appropriate skills. – Managers [and practitioners] avoid best practices and lessons learned.
- 19. 19 Common-Sense Approach toProjects • Common-Sense Approach to Projects • Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations. • Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s way. • Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. • Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep it simple.” • Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project.
- 20. 20 To Get tothe Essence of a Project • Why is the system being developed? • What will be done? • When will it be accomplished? • Who is responsible? • Where are they organizationally located? • How will the job be done technically and managerially? • How much of each resource (e.g., people, software, tools, database) will be needed? Barry Boehm [Boe96]
- 21. 21 Critical Practices Formal riskmanagement Empirical cost and schedule estimation Metrics-based project management Earned value tracking Defect tracking against quality targets People aware project management
- 22. 22 A Good ManagerMeasures process measurement What do we use as a basis? • size? • function? project metrics process metrics product product metrics Process and Project Metrics
- 23. 23 Why Do WeMeasure? assess the status of an ongoing project • track potential risks • uncover problem areas before they go “critical,” • adjust work flow or tasks, • evaluate the project team’s ability to control quality of software work products.
- 24. 24 Process Measurement • Wemeasure the efficacy of a software process indirectly. – That is, we derive a set of metrics based on the outcomes that can be derived from the process. – Outcomes include • measures of errors uncovered before release of the software • defects delivered to and reported by end-users • work products delivered (productivity) • human effort expended • calendar time expended • schedule conformance • other measures. • We also derive process metrics by measuring the characteristics of specific software engineering tasks.
- 25. 25 Process Metrics Guidelines •Use common sense and organizational sensitivity when interpreting metrics data. • Provide regular feedback to the individuals and teams who collect measures and metrics. • Don’t use metrics to appraise individuals. • Work with practitioners and teams to set clear goals and metrics that will be used to achieve them. • Never use metrics to threaten individuals or teams. • Metrics data that indicate a problem area should not be considered “negative.” These data are merely an indicator for process improvement. • Don’t obsess on a single metric to the exclusion of other important metrics.
- 26. 26 Software Process Improvement SPI Process model Improvementgoals Process metrics Process improvement recommendations
- 27. 27 Process Metrics Quality-related focus on quality of work products and deliverables Productivity-related Production of work-products related to effort expended Statistical SQA data error categorization & analysis Defect removal efficiency propagation of errors from process activity to activity Reuse data The number of components produced and their degree of reusability
- 28. 28 Project Metrics usedto minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality. every project should measure: inputs—measures of the resources (e.g., people, tools) required to do the work. outputs—measures of the deliverables or work products created during the software engineering process. results—measures that indicate the effectiveness of the deliverables.
- 29. 29 Typical Project Metrics •Effort/time per software engineering task • Errors uncovered per review hour • Scheduled vs. actual milestone dates • Changes (number) and their characteristics • Distribution of effort on software engineering tasks
- 30. 30 Software Project Planning Theoverall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. Why? So the end result gets done on time, with quality! Estimation for Software Projects
- 31. 31 Project Planning TaskSet-I • Establish project scope • Determine feasibility • Analyze risks • Define required resources – Determine require human resources – Define reusable software resources – Identify environmental resources
- 32. 32 Project Planning TaskSet-II • Estimate cost and effort – Decompose the problem – Develop two or more estimates using size, function points, process tasks or use-cases – Reconcile the estimates • Develop a project schedule • Establish a meaningful task set • Define a task network • Use scheduling tools to develop a timeline chart • Define schedule tracking mechanisms
- 33. 33 Estimation • Estimation ofresources, cost, and schedule for a software engineering effort requires – experience – access to good historical information (metrics) – the courage to commit to quantitative predictions when qualitative information is all that exists • Estimation carries inherent risk and this risk leads to uncertainty
- 34. 34 Write it Down! Software Project Plan ProjectScope Estimates Risks Schedule Control strategy
- 35. 35 Estimation Techniques • Past(similar) project experience • Conventional estimation techniques – task breakdown and effort estimates – size (e.g., FP) estimates • Empirical models • Automated tools
- 36.
- 37. 37 Conventional Methods: LOC/FPApproach • Compute LOC/FP using estimates of information domain values • Use historical data to build estimates for the project
- 38. 38 Example: LOC Approach Averageproductivity for systems of this type = 620 LOC/pm. Burdened labor rate =$8000 per month, the cost per line of code is approximately $13. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-months.
- 39. 39 Example: FP Approach Theestimated number of FP is derived: FPestimated = count-total * [0.65 + 0.01 * S (Fi)] FPestimated = 375 organizational average productivity = 6.5 FP/pm. burdened labor rate = $8000 per month, approximately $1230/FP. Based on the FP estimate and the historical productivity data, total estimated project cost is $461,000 and estimated effort is 58 person-months.
- 40. 40 Empirical Estimation Models Generalform: effort = tuning coefficient * size exponent usually derived as person-months of effort required either a constant or a number derived based on complexity of project usually LOC but may also be function point empirically derived
- 41. 41 COCOMO-II • COCOMO IIis actually a hierarchy of estimation models that address the following areas: • Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. • Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. • Post-architecture-stage model. Used during the construction of the software.
- 42. 42 What is Risk? •Risks are potential problems that may affect successful completion of a software project. • Risks involve uncertainty and potential losses. • Risk analysis and management are intended to help a software team understand and manage uncertainty during the development process.
- 44. 44 Risk Strategies Reactive strategies –very common, also known as fire fighting – project team sets resources aside to deal with problems – team does nothing until a risk becomes a problem • Proactive strategies – risk management begins long before technical work starts, risks are identified and prioritized by importance – team builds a plan to avoid risks if they can or to minimize risks if they turn into problems
- 45. 45 Software Risks -1 Project risks – threaten the project plan • Technical risks – threaten product quality and the timeliness of the schedule • Business risks – threaten the viability of the software to be built (market risks, strategic risks, management risks, budget risks)
- 46. 46 Software Risks -2 • Known risks – predictable from careful evaluation of current project plan and those extrapolated from past project experience • Unknown risks – some problems will simply occur without warning
- 47. 47 Risk Analysis • Riskidentification • Risk projection – impact of risks/likelihood of risk actually happening • Risk assessment – what will change if risk becomes problem • Risk management
- 48. 48 Risk Identification • Product-specificrisks – the project plan and software statement of scope are examined to identify any special characteristics of the product that may threaten the project plan • Generic risks – are potential threats to every software product • product size • customer characteristics • development environment • technology to be built
- 49. 49 Risk Projection • Therisk drivers affecting each risk component are – classified according to their impact category – potential consequences of each undetected software fault or unachieved project outcome are described
- 50. 50 Risk Impact • Riskcomponents – performance – cost – support – schedule • Risk impact – negligible – marginal – critical – catastrophic
- 51. 51 Risk Estimation 1. Establisha scale indicating perceived likelihood of risk occurring 2. Determine consequences. 3. Estimate impact of consequences on project (for each risk). 4. Note overall accuracy of risk projection (to avoid misunderstandings).
- 52. 52 Risk Table Construction- 1 • List all risks in the first column of the table • Classify each risk and enter the category label in column two • Determine a probability for each risk and enter it into column three • Enter the severity of each risk (negligible, marginal, critical, catastrophic) in column four.
- 53. 53 Risks Category ProbabilityImpact RMMM Estimated size of project in LOC or FP PS 80% 2 ** Lack of needed specialization increases defects and reworks ST 50% 2 ** Unfamiliar areas of the product take more time than expected to design and implement DE 50% 2 ** Does the environment make use of a database DE 35% 3 Components developed separately cannot be integrated easily, requiring redesign DE 25% 3 Development of the wrong software functions requires redesign and implementation DE 25% 3 Development of extra software functions that are not needed DE 20% 3 Strict requirements for compatibility with existing system require more testing, design, and implementation than expected DE 20% 3 Operation in unfamiliar software environment causes unforeseen problems EV 25% 4 Team members do not work well together ST 20% 4 Key personnel are available only part-time ST 20% 4
- 54. 54 Risk Table Construction- 2 • Sort the table by probability and impact value • Determine the criteria for deciding where the sorted table will be divided into the first priority concerns and the second priority concerns • First priority concerns must be managed (a fifth column can be added to contain a pointer into the RMMM document)
- 55.
- 56. 56 Risk Refinement • Processof restating the risks as a set of more detailed risks that will be easier to mitigate, monitor, and manage. • CTC (condition-transition-consequence) format may be a good representation for the detailed risks (e.g. given that <condition> then there is a concern that (possibly) <consequence>).
- 57. 57 RMMM - 1 •Risk mitigation – proactive planning for risk avoidance • Risk monitoring – assessing whether predicted risks occur or not – ensuring risk aversion steps are being properly applied – collect information for future risk analysis – determining which risks caused which problems
- 58. 58 RMMM - 2 •Risk Management – contingency planning – actions to be taken in the event that mitigation steps have failed and the risk has become a live problem
- 59. 59 Risk Mitigation Example Risk:loss of key team members • Determine causes of job turnover. • Eliminate causes before project starts. • After project starts, assume turnover is going to occur and work to ensure continuity. • Make sure teams are organized and distribute information widely. • Define documentation standards and be sure documents are produced in a
- 60. 60 Risk Information Sheets •Alternative to RMMM plan in which each risk is documented individually. • Often risk information sheets (RIS) are maintained using a database system. • RIS components – risk id, date, probability, impact, description – refinement, mitigation/monitoring – management/contingency/trigger – status – originator, assigned staff member
- 61. 61 Why Are ProjectsLate? • an unrealistic deadline established by someone outside the software development group • changing customer requirements that are not reflected in schedule changes; • an honest underestimate of the amount of effort and/or the number of resources that will be required to do the job; • predictable and/or unpredictable risks that were not considered when the project commenced; • technical difficulties that could not have been foreseen in advance; • human difficulties that could not have been foreseen in advance; • miscommunication among project staff that results in delays; • a failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem Project Scheduling
- 62. 62 Scheduling Principles • compartmentalization—definedistinct tasks • interdependency—indicate task interrelationship • effort validation—be sure resources are available • defined responsibilities—people must be assigned • defined outcomes—each task must have an output • defined milestones—review for quality
- 63. 63 Defining Task Sets •determine type of project • assess the degree of rigor required • identify adaptation criteria • select appropriate software engineering tasks
- 64. 64 Task Set Refinement 1.1Concept scoping determines the overall scope of the project. Task definition: Task 1.1 Concept Scoping 1.1.1 Identify need, benefits and potential customers; 1.1.2 Define desired output/control and input events that drive the application; Begin Task 1.1.2 1.1.2.1 FTR: Review written description of need FTR indicates that a formal technical review (Chapter 26) is to be conducted. 1.1.2.2 Derive a list of customer visible outputs/inputs 1.1.2.3 FTR: Review outputs/inputs with customer and revise as required; endtask Task 1.1.2 1.1.3 Define the functionality/behavior for each major function; Begin Task 1.1.3 1.1.3.1 FTR: Review output and input data objects derived in task 1.1.2; 1.1.3.2 Derive a model of functions/behaviors; 1.1.3.3 FTR: Review functions/behaviors with customer and revise as required; endtask Task 1.1.3 1.1.4 Isolate those elements of the technology to be implemented in software; 1.1.5 Research availability of existing software; 1.1.6 Define technical feasibility; 1.1.7 Make quick estimate of size; 1.1.8 Create a Scope Definition; endTask definition: Task 1.1 is refined to
- 65. 65 Timeline Charts Tasks Week1 Week 2 Week 3 Week 4 Week n Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 10 Task 11 Task 12
- 66. 66 Use Automated Toolsto Derive a Timeline Chart
- 67. 67 Schedule Tracking – ScheduleTracking – conduct periodic project status meetings in which each team member reports progress and problems. – evaluate the results of all reviews conducted throughout the software engineering process. – determine whether formal project milestones (the diamonds shown in Figure 27.3) have been accomplished by the scheduled date. – compare actual start-date to planned start-date for each project task listed in the resource table (Figure 27.4). – meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon. – use earned value analysis to assess progress quantitatively.
- 68. 68 Earned Value Analysis(EVA) • Earned value – is a measure of progress – enables us to assess the “percent of completeness” of a project using quantitative analysis rather than rely on a gut feeling – “provides accurate and reliable readings of performance from as early as 15 percent into the project.” [Fle98]
- 69. 69 Computing Earned Value-I •The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. – BCWSi is the effort planned for work task i. – To determine progress at a given point along the project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule. • The BCWS values for all work tasks are summed to derive the budget at completion, BAC. Hence, BAC = ∑ (BCWSk) for all tasks k
- 70. 70 Computing Earned Value-II •Next, the value for budgeted cost of work performed (BCWP) is computed. – The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule. • “the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned to be completed and the latter represents the budget of the activities that actually were completed.” [Wil99] • Given values for BCWS, BAC, and BCWP, important progress indicators can be computed: • Schedule performance index, SPI = BCWP/BCWS • Schedule variance, SV = BCWP – BCWS • SPI is an indication of the efficiency with which the project is utilizing scheduled resources.
- 71. 71 Computing Earned Value-III •Percent scheduled work completion = BCWS/BAC – provides an indication of the percentage of work that should have been completed by time t. • Percent complete = BCWP/BAC – provides a quantitative indication of the percent of completeness of the project at a given point in time, t. • Actual cost of work performed, ACWP, is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule. It is then possible to compute • Cost performance index, CPI = BCWP/ACWP • Cost variance, CV = BCWP – ACWP
- 72. AssignmentSubmit handwritten answers ina folder with in 7 days from today • 1. Provide at least five examples of how the law of unintended consequences applies to computer software. • 2. Provide detailed examples (both positive and negative) that indicate the impact of software on our society. • 3. Many modern applications change frequently—before they are presented to the end user and then after the first version has been put into use. Suggest a few ways to build software to stop deterioration due to change. • 4. Consider the seven software categories presented. Do you think that the same approach to software engineering can be applied for each? Explain your answer • 5.Software Estimation Tools, Techniques & Benchmarks ...Also take a example of COI Administration - Software developemnt task and make an estimate of TIME,COST,EFFORT,PEOPLE,MANHOURS- for it using one of the ACEIT These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 72