Muutke küpsiste eelistusi

E-raamat: Trustworthy Systems Through Quantitative Software Engineering: Theory and Practice for Trustworthy Systems [Wiley Online]

,
Teised raamatud teemal:
  • Wiley Online
  • Hind: 169,17 €*
  • * hind, mis tagab piiramatu üheaegsete kasutajate arvuga ligipääsu piiramatuks ajaks
Trustworthy Systems Through Quantitative Software Engineering: Theory and Practice for Trustworthy SystemsSuurem pilt
Teised raamatud teemal:
Wiley Online e-raamatudRohkem infot Wiley Online kohta
Raamatu kodulehekülg: https://onlinelibrary.wiley.com/doi/book/10.1002/0471750336
Software engineers are under more pressure than ever to meet customers' needs while keeping projects on schedule and under budget. This text, which doubles as a university course text and a self-study guide, uses a problem analysis approach and a practical attitude in developing a model for quantitative software engineering, covering acquiring the engineering mindset, working with the "Big Four" (people, product, process, project), maintaining ethics and professionalism in software requirements, and in prototyping, architecture, estimation, planning, investment, and design for trustworthiness, taking the measure of the system by identifying and managing risk, taking human factors into consideration, paying attention to details, and managing testing and configuration. The final chapter is a project description for students to follow. Annotation ©2005 Book News, Inc., Portland, OR (booknews.com)

A benchmark text on software development and quantitative software engineering

"We all trust software. All too frequently, this trust is misplaced. Larry Bernstein has created and applied quantitative techniques to develop trustworthy software systems. He and C. M. Yuhas have organized this quantitative experience into a book of great value to make software trustworthy for all of us."
-Barry Boehm

Trustworthy Systems Through Quantitative Software Engineering proposes a novel, reliability-driven software engineering approach, and discusses human factors in software engineering and how these affect team dynamics. This practical approach gives software engineering students and professionals a solid foundation in problem analysis, allowing them to meet customers' changing needs by tailoring their projects to meet specific challenges, and complete projects on schedule and within budget.

Specifically, it helps developers identify customer requirements, develop software designs, manage a software development team, and evaluate software products to customer specifications. Students learn "magic numbers of software engineering," rules of thumb that show how to simplify architecture, design, and implementation.

Case histories and exercises clearly present successful software engineers' experiences and illustrate potential problems, results, and trade-offs. Also featuring an accompanying Web site with additional and related material, Trustworthy Systems Through Quantitative Software Engineering is a hands-on, project-oriented resource for upper-level software and computer science students, engineers, professional developers, managers, and professionals involved in software engineering projects.

An Instructor's Manual presenting detailed solutions to all the problems in the book is available from the Wiley editorial department.

An Instructor Support FTP site is also available.

PREFACE xvii
ACKNOWLEDGMENT xxv
PART 1 GETTING STARTED 1(72)
1. Think Like an Engineer—Especially for Software
3(36)
1.1 Making a Judgment
4(2)
1.2 The Software Engineer's Responsibilities
6(1)
1.3 Ethics
6(5)
1.4 Software Development Processes
11(1)
1.5 Choosing a Process
12(14)
1.5.1 No-Method "Code and Fix" Approach
15(1)
1.5.2 Waterfall Model
16(2)
1.5.3 Planned Incremental Development Process
18(1)
1.5.4 Spiral Model: Planned Risk Assessment-Driven Process
18(5)
1.5.5 Development Plan Approach
23(2)
1.5.6 Agile Process: an Apparent Oxymoron
25(1)
1.6 Reemergence of Model-Based Software Development
26(1)
1.7 Process Evolution
27(2)
1.8 Organization Structure
29(2)
1.9 Principles of Sound Organizations
31(2)
1.10 Short Projects-4 to 6 Weeks
33(2)
1.10.1 Project 1: Automating Library Overdue Book Notices
33(1)
1.10.2 Project 2: Ajax Transporters, Inc. Maintenance Project
34(1)
1.11 Problems
35(4)
2. People, Product, Process, Project—The Big Four
39(34)
2.1 People: Cultivate the Guru and Support the Majority
40(5)
2.1.1 How to Recognize a Guru
41(1)
2.1.2 How to Attract a Guru to Your Project
42(1)
2.1.3 How to Keep Your Gurus Working
43(1)
2.1.4 How to Support the Majority
43(2)
2.2 Product: "Buy Me!"
45(4)
2.2.1 Reliable Software Products
46(1)
2.2.2 Useful Software Products
47(1)
2.2.3 Good User Experience
48(1)
2.3 Process: "OK, How Will We Build This?"
49(12)
2.3.1 Agile Processes
49(4)
2.3.2 Object-Oriented Opportunities
53(7)
2.3.3 Meaningful Metrics
60(1)
2.4 Project: Making It Work
61(4)
2.5 Problems
65(2)
2.6 Additional Problems Based on Case Studies
67(6)
PART 2 ETHICS AND PROFESSIONALISM 73(202)
3. Software Requirements
75(32)
3.1 What Can Go Wrong With Requirements
75(1)
3.2 The Formal Processes
76(5)
3.3 Robust Requirements
81(3)
3.4 Requirements Synthesis
84(2)
3.5 Requirements Specification
86(1)
3.6 Quantitative Software Engineering Gates
87(1)
3.7 sQFD
88(3)
3.8 ICED-T Metrics
91(4)
3.8.1 ICED-T Insights
92(2)
3.8.2 Using the ICED-T Model
94(1)
3.9 Development Sizing and Scheduling With Function Points
95(3)
3.9.1 Function Point Analysis Experience
95(1)
3.9.2 NCSLOC vs Function Points
96(1)
3.9.3 Computing Simplified Function Points (sFP)
97(1)
3.10 Case Study: The Case of the Emergency No-Show Service
98(5)
3.11 Problems
103(4)
4. Prototyping
107(30)
4.1 Make It Work; Then Make It Work Right
107(4)
4.1.1 How to Get at the Governing Requirements
108(1)
4.1.2 Rapid Application Prototype
108(2)
4.1.3 What's Soft Is Hard
110(1)
4.2 So What Happens Monday Morning?
111(5)
4.2.1 What Needs to Be Prototyped?
111(1)
4.2.2 How Do You Build a Prototype?
112(1)
4.2.3 How Is the Prototype Used?
112(2)
4.2.4 What Happens to the Prototype?
114(2)
4.3 It Works, But Will It Continue to Work?
116(1)
4.4 Case Study: The Case of the Driven Development
116(12)
4.4.1 Significant Results
119(3)
4.4.2 Lessons Learned
122(1)
4.4.3 Additional Business Histories
123(5)
4.5 Why Is Prototyping So Important?
128(2)
4.6 Prototyping Deficiencies
130(1)
4.7 Iterative Prototyping
130(1)
4.8 Case Study: The Case of the Famished Fish
131(2)
4.9 Problems
133(4)
5. Architecture
137(36)
5.1 Architecture Is a System's DNA
137(2)
5.2 Pity the Poor System Administrator
139(2)
5.3 Software Architecture Experience
141(1)
5.4 Process and Model
142(2)
5.5 Components
144(4)
5.5.1 Components as COTS
144(1)
5.5.2 Encapsulation and Abstraction
145(1)
5.5.3 Ready or Not, Objects Are Here
146(2)
5.6 UNIX
148(1)
5.7 TL1
149(4)
5.7.1 Mission
150(1)
5.7.2 Comparative Analysis
151(1)
5.7.3 Message Formatting
152(1)
5.7.4 TL1 Message Formulation
152(1)
5.7.5 Industry Support of TL1
152(1)
5.8 Documenting the Architecture
153(2)
5.8.1 Debriefing Report
154(1)
5.8.2 Lessons Learned
154(1)
5.8.3 Users of Architecture Documentation
154(1)
5.9 Architecture Reviews
155(1)
5.10 Middleware
156(2)
5.11 How Many Times Before We Learn?
158(5)
5.11.1 Comair Cancels 1100 Flights on Christmas 2004
158(1)
5.11.2 Air Traffic Shutdown in September 2004
159(1)
5.11.3 NASA Crashes into Mars, 2004
159(1)
5.11.4 Case Study: The Case of the Preempted Priorities
160(3)
5.12 Financial Systems Architecture
163(3)
5.12.1 Typical Business Processes
163(1)
5.12.2 Product-Related Layer in the Architecture
164(1)
5.12.3 Finding Simple Components
165(1)
5.13 Design and Architectural Process
166(4)
5.14 Problems
170(3)
6. Estimation, Planning, and Investment
173(50)
6.1 Software Size Estimation
174(2)
6.1.1 Pitfalls and Pratfalls
174(1)
6.1.2 Software Size Metrics
175(1)
6.2 Function Points
176(1)
6.2.1 Fundamentals of FPA
176(1)
6.2.2 Brief History
176(1)
6.2.3 Objectives of FPA
177(1)
6.2.4 Characteristics of Quality FPA
177(1)
6.3 Five Major Elements of Function Point Counting
177(2)
6.3.1 EI
177(1)
6.3.2 E0
178(1)
6.3.3 EQ
178(1)
6.3.4 ILF
178(1)
6.3.5 EIF
179(1)
6.4 Each Element Can Be Simple, Average, or Complex
179(3)
6.5 Sizing an Automation Project With FPA
182(4)
6.5.1 Advantages of Function Point Measurement
183(1)
6.5.2 Disadvantages of Function Point Measurement
184(1)
6.5.3 Results Common to FPA
184(1)
6.5.4 FPA Accuracy
185(1)
6.6 NCSLOC Metric
186(6)
6.6.1 Company Statistics
187(1)
6.6.2 Reuse
187(2)
6.6.3 Wideband Delphi
189(1)
6.6.4 Disadvantages of SLOC
190(2)
6.7 Production Planning
192(3)
6.7.1 Productivity
192(1)
6.7.2 Mediating Culture
192(1)
6.7.3 Customer Relations
193(1)
6.7.4 Centralized Support Functions
193(2)
6.8 Investment
195(13)
6.8.1 Cost Estimation Models
195(2)
6.8.2 COCOMO
197(8)
6.8.3 Scheduling Tools—PERT, Gantt
205(2)
6.8.4 Project Manager's Job
207(1)
6.9 Example: Apply the Process to a Problem
208(8)
6.9.1 Prospectus
208(1)
6.9.2 Measurable Operational Value (MOV)
209(1)
6.9.3 Requirements Specification
209(5)
6.9.4 Schedule, Resources, Features—What to Change?
214(2)
6.10 Additional Problems
216(7)
7. Design for Trustworthiness
223(52)
7.1 Why Trustworthiness Matters
224(1)
7.2 Software Reliability Overview
225(3)
7.3 Design Reviews
228(15)
7.3.1 Topics for Design Reviews
229(1)
7.3.2 Modules, Interfaces, and Components
230(4)
7.3.3 Interfaces
234(2)
7.3.4 Software Structure Influences Reliability
236(2)
7.3.5 Components
238(1)
7.3.6 Open&Closed Principle
238(1)
7.3.7 The Liskov Substitution Principle
239(1)
7.3.8 Comparing Object-Oriented Programming With Componentry
240(1)
7.3.9 Politics of Reuse
240(3)
7.4 Design Principles
243(3)
7.4.1 Strong Cohesion
243(1)
7.4.2 Weak Coupling
243(1)
7.4.3 Information Hiding
244(1)
7.4.4 Inheritance
244(1)
7.4.5 Generalization Abstraction
244(1)
7.4.6 Separation of Concerns
245(1)
7.4.7 Removal of Context
245(1)
7.5 Documentation
246(2)
7.6 Design Constraints That Make Software Trustworthy
248(20)
7.6.1 Simplify the Design
248(1)
7.6.2 Software Fault Tolerance
249(2)
7.6.3 Software Rejuvenation
251(3)
7.6.4 Hire Good People and Keep Them
254(1)
7.6.5 Limit the Language Features Used
254(1)
7.6.6 Limit Module Size and Initialize Memory
255(1)
7.6.7 Check the Design Stability
255(4)
7.6.8 Bound the Execution Domain
259(1)
7.6.9 Engineer to Performance Budgets
260(3)
7.6.10 Reduce Algorithm Complexity
263(3)
7.6.11 Factor and Refactor
266(2)
7.7 Problems
268(7)
PART 3 TAKING THE MEASURE OF THE SYSTEM 275(154)
8. Identifying and Managing Risk
277(32)
8.1 Risk Potential
278(1)
8.2 Risk Management Paradigm
279(1)
8.3 Functions of Risk Management
279(1)
8.4 Risk Analysis
280(2)
8.5 Calculating Risk
282(4)
8.6 Using Risk Assessment in Project Development: The Spiral Model
286(3)
8.7 Containing Risks
289(10)
8.7.1 Incomplete and Fuzzy Requirements
289(1)
8.7.2 Schedule Too Short
290(1)
8.7.3 Not Enough Staff
291(1)
8.7.4 Morale of Key Staff Is Poor
292(3)
8.7.5 Stakeholders Are Losing Interest
295(1)
8.7.6 Untrustworthy Design
295(1)
8.7.7 Feature Set Is Not Economically Viable
296(1)
8.7.8 Feature Set Is Too Large
296(1)
8.7.9 Technology Is Immature
296(2)
8.7.10 Late Planned Deliveries of Hardware and Operating System
298(1)
8.8 Manage the Cost Risk to Avoid Outsourcing
299(4)
8.8.1 Technology Selection
300(1)
8.8.2 Tools
300(1)
8.8.3 Software Manufacturing
300(1)
8.8.4 Integration, Reliability, and Stress Testing
301(1)
8.8.5 Computer Facilities
301(1)
8.8.6 Human Interaction Design and Documentation
301(2)
8.9 Software Project Management Audits
303(1)
8.10 Running an Audit
304(1)
8.11 Risks with Risk Management
304(1)
8.12 Problems
305(4)
9. Human Factors in Software Engineering
309(35)
9.1 A Click in the Right Direction
309(3)
9.2 Managing Things, Managing People
312(4)
9.2.1 Knowledge Workers
313(1)
9.2.2 Collaborative Management
313(3)
9.3 FAA Rationale for Human Factors Design
316(3)
9.4 Reach Out and Touch Something
319(1)
9.4.1 Maddening Counterintuitive Cues
319(1)
9.4.2 GUI
319(1)
9.4.3 Customer Care and Web Agents
319(1)
9.5 System Effectiveness in Human Factors Terms
320(3)
9.5.1 What to Look for in COTS
320(2)
9.5.2 Simple Guidelines for Managing Development
322(1)
9.6 How Much Should the System Do?
323(4)
9.6.1 Screen Icon Design
324(2)
9.6.2 Short- and Long-Term Memory
326(1)
9.7 Emerging Technology
327(7)
9.8 Applying the Principles to Developers
334(2)
9.9 The Bell Laboratories Philosophy
336(2)
9.10 So You Want to Be a Manager
338(1)
9.11 Problems
338(6)
10. Implementation Details
344(28)
10.1 Structured Programming
345(1)
10.2 Rational Unified Process and Unified Modeling Language
346(7)
10.3 Measuring Complexity
353(7)
10.4 Coding Styles
360(5)
10.4.1 Data Structures
360(3)
10.4.2 Team Coding
363(1)
10.4.3 Code Reading
364(1)
10.4.4 Code Review
364(1)
10.4.5 Code Inspections
364(1)
10.5 A Must Read for Trustworthy Software Engineers
365(1)
10.6 Coding for Parallelism
366(1)
10.7 Threats
366(2)
10.8 Open-Source Software
368(1)
10.9 Problems
369(3)
11. Testing and Configuration Management
372(32)
11.1 The Price of Quality
373(1)
11.1.1 Unit Testing
373(1)
11.1.2 Integration Testing
373(1)
11.1.3 System Testing
373(1)
11.1.4 Reliability Testing
374(1)
11.1.5 Stress Testing
374(1)
11.2 Robust Testing
374(2)
11.2.1 Robust Design
374(1)
11.2.2 Prototypes
375(1)
11.2.3 Identify Expected Results
375(1)
11.2.4 Orthogonal Array Test Sets (OATS)
376(1)
11.3 Testing Techniques
376(3)
11.3.1 One-Factor-at-a-Time
377(1)
11.3.2 Exhaustive
377(1)
11.3.3 Deductive Analytical Method
377(1)
11.3.4 Random Intuitive Method
377(1)
11.3.5 Orthogonal Array-Based Method
377(1)
11.3.6 Defect Analysis
378(1)
11.4 Case Study: The Case of the Impossible Overtime
379(1)
11.5 Cooperative Testing
380(2)
11.6 Graphic Footprint
382(2)
11.7 Testing Strategy
384(2)
11.7.1 Test Incrementally
384(1)
11.7.2 Test Under No-Load
384(1)
11.7.3 Test Under Expected-Load
384(1)
11.7.4 Test Under Heavy-Load
384(1)
11.7.5 Test Under Overload
385(1)
11.7.6 Reject Insufficiently Tested Code
385(1)
11.7.7 Diabolic Testing
385(1)
11.7.8 Reliability Tests
385(1)
11.7.9 Footprint
385(1)
11.7.10 Regression Tests
385(1)
11.8 Software Hot Spots
386(6)
11.9 Software Manufacturing Defined
392(1)
11.10 Configuration Management
393(5)
11.11 Outsourcing
398(2)
11.11.1 Test Models
398(2)
11.11.2 Faster Iteration
400(1)
11.11.3 Meaningful Test Process Metrics
400(1)
11.12 Problems
400(4)
12. The Final Project: By Students, For Students
404(25)
12.1 How to Make the Course Work for You
404(1)
12.2 Sample Call for Projects
405(2)
12.3 A Real Student Project
407(21)
12.4 The Rest of the Story
428(1)
12.5 Our Hope
428(1)
INDEX 429


LAWRENCE BERNSTEIN is the Series Editor for the Quantitative Software Engineering Series, published by Wiley. Professor Bernstein is currently Industry Research Professor at the Stevens Institute of Technology. He previously pursued a distinguished executive career at Bell Laboratories. He is a Fellow of IEEE and ACM. C. M. YUHAS is a freelance writer who has published articles on network management in the IEEE Journal on Selected Areas in Communication and IEEE Network. She has a BA in English from Douglass College and an MA in communications from New York University.
Püsilink: https://www.kriso.ee/db/9780471750338_pe.html
Märksõnad: