Atjaunināt sīkdatņu piekrišanu

E-grāmata: Patterns for Performance and Operability: Building and Testing Enterprise Software

3.50/5 (4 ratings by Goodreads)
(Infomaxium Inc., North York, Ontario, Canada), (Capco Consulting, Toronto, Ontario, Canada), (Capco Consulting, Toronto, Ontario, Canada), (University of Waterloo, Ontario, Canada)
  • Formāts: 344 pages
  • Izdošanas datums: 22-Dec-2007
  • Izdevniecība: Auerbach
  • Valoda: eng
  • ISBN-13: 9781420053357
Citas grāmatas par šo tēmu:
  • Formāts - PDF+DRM
  • Cena: 106,44 €*
  • * ši ir gala cena, t.i., netiek piemērotas nekādas papildus atlaides
  • Ielikt grozā
  • Pievienot vēlmju sarakstam
  • Šī e-grāmata paredzēta tikai personīgai lietošanai. E-grāmatas nav iespējams atgriezt un nauda par iegādātajām e-grāmatām netiek atmaksāta.
  • Bibliotēkām
Patterns for Performance and Operability: Building and Testing Enterprise SoftwarePalielināt
  • Formāts: 344 pages
  • Izdošanas datums: 22-Dec-2007
  • Izdevniecība: Auerbach
  • Valoda: eng
  • ISBN-13: 9781420053357
Citas grāmatas par šo tēmu:

DRM restrictions

  • Kopēšana (kopēt/ievietot):

    nav atļauts

  • Drukāšana:

    nav atļauts

  • Lietošana:

    Digitālo tiesību pārvaldība (Digital Rights Management (DRM))
    Izdevējs ir piegādājis šo grāmatu šifrētā veidā, kas nozīmē, ka jums ir jāinstalē bezmaksas programmatūra, lai to atbloķētu un lasītu. Lai lasītu šo e-grāmatu, jums ir jāizveido Adobe ID. Vairāk informācijas šeit. E-grāmatu var lasīt un lejupielādēt līdz 6 ierīcēm (vienam lietotājam ar vienu un to pašu Adobe ID).

    Nepieciešamā programmatūra
    Lai lasītu šo e-grāmatu mobilajā ierīcē (tālrunī vai planšetdatorā), jums būs jāinstalē šī bezmaksas lietotne: PocketBook Reader (iOS / Android)

    Lai lejupielādētu un lasītu šo e-grāmatu datorā vai Mac datorā, jums ir nepieciešamid Adobe Digital Editions (šī ir bezmaksas lietotne, kas īpaši izstrādāta e-grāmatām. Tā nav tas pats, kas Adobe Reader, kas, iespējams, jau ir jūsu datorā.)

    Jūs nevarat lasīt šo e-grāmatu, izmantojot Amazon Kindle.

Structured to follow the software life cycle, Patterns for Performance and Operability provides advice and examples-based instructions at every phase. You can read it from start to finish or go directly to those chapters that interest you the most. Whatever approach you choose, you will learn:

How to:

· Define and document comprehensive non-functional requirements for any software system

· Define scope and logistics for non-functional test activities

· Execute non-functional tests and report results clearly and effectively

· Patterns for defensive software designs in common software scenarios that promote operability and availability

· Implement the right level of reporting, monitoring, and trending for highly available production software systems

Patterns for:

· Software designs that support simpler and more efficient operation in a production environment

· Software design that support high-performance and scalability

Strategies and Techniques for:

· Techniques for managing and troubleshooting during a production crisis

· Strategies for resisting project pressure to compromise on quality or completeness of non-functional activities in the software cycle

Recenzijas

". . . written in an easy to read and logical format . . . The concepts and principles in this book will never be outdated . . . I recommend this book to anyone who has a responsibility and interest in improving the quality of enterprise software. Whether you are deploying your software internally at your own organization or externally for customers reading this book and implementing the principles (assuming this is not already being done) will undoubtedly improve the quality of your system and will lead to an improved computing experience for your end users."

Alan Madick, in StickyMinds.com, January 2009

Dedications v
The Purpose of This Book xv
Acknowledgments xvii
About the Authors xix
Introduction
1(16)
Production Systems in the Real World
1(6)
Case 1---The Case of the Puzzlingly Poor Performance
2(3)
Case 2---The Case of the Disappearing Database
5(2)
Why Should I Read This Book?
7(1)
The Non-Functional Systems Challenge
8(1)
What Is Covered by Non-Functional Testing
9(1)
Planning for the Unexpected
10(1)
Patterns for Operability in Application Design
11(3)
Ensuring Data and Transaction Integrity
11(1)
Capturing and Reporting Exception Conditions in a Consistent Fashion
11(3)
Automated Recovery from Exception Conditions
14(1)
Application Availability and Health
14(1)
Summary
14(3)
Planning and Project Initiation
17(24)
The Business Case for Non-Functional Testing
17(5)
What Should Be Tested
17(2)
How Far Should the System Be Tested?
19(1)
Justifying the Investment
20(1)
Negative Reasoning
21(1)
Scoping and Estimating
22(11)
Determining the Scope of Non-Functional Testing
22(4)
Estimating Effort and Resource
26(3)
Estimating the Delivery Timeline
29(4)
Test and Resource Planning
33(6)
Test Types and Base Requirements
33(3)
Test Environments
36(1)
The Test Team
37(2)
Communication Planning
39(1)
Setting Expectations
39(1)
Summary
40(1)
Non-Functional Requirements
41(28)
What Are Non-Functional Requirements?
43(1)
Do I Need Non-Functional Requirements?
43(1)
Roles and Responsibilities
44(1)
Challenging Requirements
45(1)
Establishing a Business Usage Model
46(10)
Quantifying Human and Machine Inputs
46(8)
Expressing Load Scenarios
54(2)
Non-Functional Requirements
56(11)
An Important Clarification
56(2)
Performance Requirements
58(4)
Operability Requirements
62(2)
Availability Requirements
64(1)
Archive Requirements
65(2)
Summary
67(2)
Designing for Operability
69(26)
Error Categorization
70(1)
Design Patterns
71(4)
Retry for Fault Tolerance
71(3)
Software Fuses
74(1)
Software Valves
75(5)
System Health Checks
78(2)
The Characteristics of a Robust System
80(11)
Simple Is Better
80(1)
Application Logging
81(2)
Transparency: Visibility into System State
83(1)
Traceability and Reconciliation
84(2)
Resume versus Abort
86(1)
Exception Handling
87(4)
Infrastructure Services
91(1)
Design Reviews
91(1)
The Design Checklist
91(1)
The Operability Review
92(2)
Summary
94(1)
Designing for Performance
95(44)
Requirements
95(6)
The ``Ilities''
95(6)
Architecture
101(1)
Hotspots
101(1)
Patterns
102(10)
Divide and Conquer
102(1)
Load Balancing
102(1)
Parallelism
103(4)
Synchronous versus Asynchronous Execution
107(2)
Caching
109(3)
Antipatterns
112(7)
Overdesign
114(1)
Overserialization
114(3)
Oversynchronization
117(1)
User Session Memory Consumption
118(1)
Algorithms
119(1)
Technology
120(6)
Programming Languages
120(3)
Distributed Processing
123(2)
XML
125(1)
Software
126(8)
Databases
127(2)
Application Servers
129(1)
Messaging Middleware
129(3)
ETLs
132(2)
Hardware Infrastructure
134(2)
Resources
134(2)
Summary
136(3)
Test Planning
139(20)
Defining Your Scope
140(5)
System Boundaries
140(2)
Scope of Operability
142(3)
Scope of Performance
145(1)
Load Testing Software
145(4)
Product Features
146(1)
Vendor Products
147(2)
Additional Testing Apparatus
149(1)
Test Beds
150(1)
Test-Case Data
150(1)
Test Environments
151(3)
Isolation
151(2)
Capacity
153(1)
Change Management
154(1)
Historical Data
154(3)
Summary
157(2)
Test Preparation and Execution
159(36)
Preparation Activities
159(1)
Script Development
160(11)
Validating the Test Environment
164(1)
Establishing Mixed Load
164(3)
Seeding the Test Bed
167(1)
Tuning the Load
167(4)
Performance Testing
171(10)
Priming Effects
172(1)
Performance Acceptance
173(3)
Reporting Performance Results
176(1)
Performance Regression: Baselining
177(4)
Stress Testing
181(1)
Operability Testing
181(7)
Boundary Condition Testing
182(1)
Failover Testing
183(3)
Fault Tolerance Testing
186(2)
Sustainability Testing
188(4)
Challenges
192(2)
Repeatable Results
193(1)
Limitations
193(1)
Summary
194(1)
Deployment Strategies
195(12)
Procedure Characteristics
196(1)
Packaging
197(1)
Configuration
197(1)
Deployment Rehearsal
198(1)
Rollout Strategies
198(2)
The Pilot Strategy
198(1)
The Phased Rollout Strategy
199(1)
The Big Bang Strategy
199(1)
The Leapfrog Strategy
200(1)
Case Study: Online Banking
200(2)
Case Study: The Banking Front Office
202(2)
Back-Out Strategies
204(1)
Complete Back-Out
204(1)
Partial Back-Out
204(1)
Logical Back-Out
204(1)
Summary
205(2)
Resisting Pressure from the Functional Requirements Stream
207(18)
A Question of Degree
208(1)
Pressures from the Functional Requirements Stream
209(3)
Attention
212(1)
Human Resources
212(1)
Hardware Resources
213(1)
Software Resources
213(1)
Issue Resolution
213(1)
Defining Success
213(1)
Setting the Stage for Success
214(9)
Framework
215(1)
Roles and Responsibilities
216(1)
Raw Resources Required by the Non-Functional Requirements Stream
216(5)
Performance Metrics
221(1)
Setting Expectations
222(1)
Controls
222(1)
The Impact of Not Acting
223(1)
Summary
223(2)
Operations Trending and Monitoring
225(32)
Monitoring
225(16)
Attributes of Effective Monitoring
227(1)
Monitoring Scope
228(2)
Infrastructure Monitoring
230(3)
Container Monitoring
233(5)
Application Monitoring
238(1)
End-User Monitoring
239(2)
Trending and Reporting
241(2)
Historical Reporting
241(1)
Performance Trending
241(2)
Error Reporting
243(2)
Reconciliation
244(1)
Business Usage Reporting
245(1)
Capacity Planning
245(11)
Planning Inputs
245(3)
Best Practice
248(1)
Case Study: Online Dating
248(7)
Maintaining the Model
255(1)
Completing a Capacity Plan
255(1)
Summary
256(1)
Troubleshooting and Crisis Management
257(20)
Reproducing the Issue
257(1)
Determining Root Cause
258(1)
Troubleshooting Strategies
259(11)
Understanding Changes in the Environment
259(2)
Gathering All Possible Inputs
261(2)
Approach Based on Type of Failure
263(2)
Predicting Related Failures
265(3)
Discouraging Bias
268(1)
Pursuing Parallel Paths
268(1)
Considering System Age
269(1)
Working Around the Problem
269(1)
Applying a Fix
270(2)
Fix versus Mitigation versus Tolerance
270(1)
Assessing Level of Testing
271(1)
Post-Mortem Review
272(3)
Reviewing the Root Cause
272(1)
Reviewing Monitoring
272(3)
Summary
275(2)
Common Impediments to Good Design
277(18)
Design Dependencies
277(2)
What Is the Definition of Good Design?
279(7)
What Are the Objectives of Design Activities?
279(2)
Rating a Design
281(5)
Testing a Design
286(1)
Contributors to Bad Design
287(1)
Common Impediments to Good Design
287(5)
Confusing Architecture with Design
288(1)
Insufficient Time/Tight Timeframes
288(1)
Missing Design Skills on the Project Team
288(1)
Lack of Design Standards
288(1)
Personal Design Preferences
289(1)
Insufficient Information
289(1)
Constantly Changing Technology
289(1)
Fad Designs
290(1)
Trying to Do Too Much
290(1)
The 80/20 Rule
290(1)
Minimalistic Viewpoint
290(1)
Lack of Consensus
291(1)
Constantly Changing Requirements
291(1)
Bad Decisions/Incorrect Decisions
291(1)
Lack of Facts
291(1)
External Impacts
291(1)
Insufficient Testing
291(1)
Lack of Design Tools
292(1)
Design Patterns Matter
292(1)
Lack of Financial Resources
292(1)
Design Principles
292(1)
Summary
293(2)
References 295(2)
Index 297


Chris Ford, Ido Gileadi, Sanjiv Purba, Mike Moerman
Biežāk uzdotie jautājumi par e-grāmatām Biežāk uzdotie jautājumi par e-grāmatām
Permanent link: https://www.kriso.lv/db/97814200533572e.html
Keywords: