Muutke küpsiste eelistusi

E-raamat: Managing Technical Debt: Reducing Friction in Software Development

  • Formaat - EPUB+DRM
  • Hind: 30,41 €*
  • * hind on lõplik, st. muud allahindlused enam ei rakendu
  • Lisa ostukorvi
  • Lisa soovinimekirja
  • See e-raamat on mõeldud ainult isiklikuks kasutamiseks. E-raamatuid ei saa tagastada.

DRM piirangud

  • Kopeerimine (copy/paste):

    ei ole lubatud

  • Printimine:

    ei ole lubatud

  • Kasutamine:

    Digitaalõiguste kaitse (DRM)
    Kirjastus on väljastanud selle e-raamatu krüpteeritud kujul, mis tähendab, et selle lugemiseks peate installeerima spetsiaalse tarkvara. Samuti peate looma endale  Adobe ID Rohkem infot siin. E-raamatut saab lugeda 1 kasutaja ning alla laadida kuni 6'de seadmesse (kõik autoriseeritud sama Adobe ID-ga).

    Vajalik tarkvara
    Mobiilsetes seadmetes (telefon või tahvelarvuti) lugemiseks peate installeerima selle tasuta rakenduse: PocketBook Reader (iOS / Android)

    PC või Mac seadmes lugemiseks peate installima Adobe Digital Editionsi (Seeon tasuta rakendus spetsiaalselt e-raamatute lugemiseks. Seda ei tohi segamini ajada Adober Reader'iga, mis tõenäoliselt on juba teie arvutisse installeeritud )

    Seda e-raamatut ei saa lugeda Amazon Kindle's. 


“This is an incredibly wise and useful book. The authors have considerable real-world experience in delivering quality systems that matter, and their expertise shines through in these pages. Here you will learn what technical debt is, what is it not, how to manage it, and how to pay it down in responsible ways. This is a book I wish I had when I was just beginning my career. The authors present a myriad of case studies, born from years of experience, and offer a multitude of actionable insights for how to apply it to your project.”
–Grady Booch, IBM Fellow

Master Best Practices for Managing Technical Debt to Promote Software Quality and Productivity

As software systems mature, earlier design or code decisions made in the context of budget or schedule constraints increasingly impede evolution and innovation. This phenomenon is called technical debt, and practical solutions exist. In Managing Technical Debt, three leading experts introduce integrated, empirically developed principles and practices that any software professional can use to gain control of technical debt in any software system.

Using real-life examples, the authors explain the forms of technical debt that afflict software-intensive systems, their root causes, and their impacts. They introduce proven approaches for identifying and assessing specific sources of technical debt, limiting new debt, and “paying off” debt over time. They describe how to establish managing technical debt as a core software engineering practice in your organization.
  • Discover how technical debt damages manageability, quality, productivity, and morale–and what you can do about it
  • Clarify root causes of debt, including the linked roles of business goals, source code, architecture, testing, and infrastructure
  • Identify technical debt items, and analyze their costs so you can prioritize action
  • Choose the right solution for each technical debt item: eliminate, reduce, or mitigate
  • Integrate software engineering practices that minimize new debt

Managing Technical Debt will be a valuable resource for every software professional who wants to accelerate innovation in existing systems, or build new systems that will be easier to maintain and evolve.

Foreword xiii
Preface xv
Acknowledgments xix
About the Authors xxi
About the Contributors xxiii
Acronyms xxv
SEI Figures for Managing Technical Debt xxvii
Part I Exploring the Technical Debt Landscape
1(48)
Chapter 1 Friction in Software Development
3(16)
The Promise of Managing Technical Debt
3(2)
Technical Debt A-B-C
5(1)
Examples of Technical Debt
6(5)
Your Own Story About Technical Debt?
11(1)
Who Is This Book For?
12(1)
Principles of Technical Debt Management
13(1)
Navigating the Concepts of the Book
14(2)
What Can You Do Today?
16(1)
For Further Reading
17(2)
Chapter 2 What Is Technical Debt?
19(18)
Mapping the Territory
19(1)
The Technical Debt Landscape
20(2)
Technical Debt Items: Artifacts, Causes, and Consequences
22(2)
Principal and Interest
24(3)
Cost and Value
27(5)
Potential Debt versus Actual Debt
32(1)
The Technical Debt Timeline
33(2)
What Can You Do Today?
35(1)
For Further Reading
35(2)
Chapter 3 Moons of Saturn---The Crucial Role of Context
37(12)
"ItDepends..."
37(2)
Three Case Studies: Moons of Saturn
39(5)
Technical Debt in Context
44(4)
What Can You Do Today?
48(1)
For Further Reading
48(1)
Part II Analyzing Technical Debt
49(66)
Chapter 4 Recognizing Technical Debt
51(14)
Where Does It Hurt?
51(3)
What Are the Visible Consequences of Technical Debt?
54(1)
Writing a Technical Debt Description
55(3)
Understanding the Business Context for Assessing Technical Debt
58(2)
Assessing Artifacts Across the Technical Debt Landscape
60(3)
What Can You Do Today?
63(1)
For Further Reading
64(1)
Chapter 5 Technical Debt and the Source Code
65(18)
Looking for the Magic Wand
65(3)
Understand Key Business Goals
68(2)
Identify Questions About the Source Code
70(2)
Define the Observable Measurement Criteria
72(3)
Select and Apply an Analysis Tool
75(1)
Document the Technical Debt Items
76(2)
Then Iterate
78(1)
What Happens Next?
79(1)
What Can You Do Today?
80(1)
For Further Reading
81(2)
Chapter 6 Technical Debt and Architecture
83(20)
Beyond the Code
83(3)
Ask the Designers
86(3)
Examine the Architecture
89(4)
Examine the Code to Get Insight into the Architecture
93(1)
The Case of Technical Debt in the Architecture of Phoebe
94(7)
What Can You Do Today?
101(1)
For Further Reading
101(2)
Chapter 7 Technical Debt and Production
103(12)
Beyond the Architecture, the Design, and the Code
103(3)
Build and Integration Debt
106(3)
Testing Debt
109(1)
Infrastructure Debt
110(1)
The Case of Technical Debt in the Production of Phoebe
110(3)
What Can You Do Today?
113(1)
For Further Reading
113(2)
Part III Deciding What Technical Debt to Fix
115(34)
Chapter 8 Costing the Technical Debt
117(14)
Shining an Economic Spotlight on Technical Debt
117(2)
Refine the Technical Debt Description
119(2)
Calculate the Cost of Remediation
121(1)
Calculate the Recurring Interest
122(1)
Compare Cost and Benefit
123(4)
Manage Technical Debt Items Collectively
127(2)
What Can You Do Today?
129(1)
For Further Reading
130(1)
Chapter 9 Servicing the Technical Debt
131(18)
Weighing the Costs and Benefits
131(5)
Paths for Servicing Technical Debt
136(6)
The Release Pipeline
142(1)
The Business Case for Technical Debt as an Investment
143(3)
What Can You Do Today?
146(1)
For Further Reading
147(2)
Part IV Managing Technical Debt Tactically and Strategically
149(58)
Chapter 10 What Causes Technical Debt?
151(16)
The Perplexing Art of Identifying What Causes Debt
151(2)
The Roots of Technical Debt
153(1)
What Causes Technical Debt?
154(1)
Causes Rooted in the Business
155(2)
Causes Arising from Change in Context
157(2)
Causes Associated with the Development Process
159(3)
Causes Arising from People and Team
162(3)
To Conclude
165(1)
What Can You Do Today?
165(1)
For Further Reading
166(1)
Chapter 11 Technical Debt Credit Check
167(12)
Identifying Causes: Technical Debt Credit Check
167(3)
Four Focus Areas for Understanding the State of a Project
170(2)
Diagnosing the Causes of Technical Debt in Phoebe
172(2)
Diagnosing the Causes of Technical Debt in Tethys
174(3)
What Can You Do Today?
177(1)
For Further Reading
178(1)
Chapter 12 Avoiding Unintentional Debt
179(16)
Software Engineering in a Nutshell
179(1)
Code Quality and Unintentional Technical Debt
180(5)
Architecture, Production, and Unintentional Technical Debt
185(8)
What Can You Do Today?
193(1)
For Further Reading
193(2)
Chapter 13 Living with Your Technical Debt
195(12)
Your Technical Debt Toolbox
195(6)
On the Three Moons of Saturn
201(3)
Technical Debt and Software Development
204(1)
Finale
205(2)
Glossary 207(2)
References 209(8)
Index 217
Philippe Kruchten is a professor of software engineering at the University of British Columbia in Vancouver, Canada. He joined academia in 2004, after a 30+-year career in industry, where he worked mostly with large software-intensive systems design in the domains of telecommunication, defense, aerospace, and transportation. Some of his experience in software development is embodied in the Rational Unified Process (RUP), whose development he directed from 1995 until 2003. Hes the author or co-author of Rational Unified Process: An Introduction (Addison-Wesley, 1998), RUP Made Easy: A Practitioners Guide (Addison-Wesley, 2003), and Software Engineering with UPEDU (Addison-Wesley, 2003), as well as earlier books about programming in Pascal and Ada. He received a doctoral degree in information systems (1986) and a mechanical engineering degree (1975) from French engineering schools.

Robert Nord is a principal researcher at the Carnegie Mellon University Software Engineering Institute, where he works to develop and communicate effective methods and practices for agile at scale, software architecture, and managing technical debt. He is coauthor of the practitioner-oriented books Applied Software Architecture (Addison-Wesley, 2000) and Documenting Software Architectures: Views and Beyond (Addison-Wesley, 2011) and lectures on architecture-centric approaches. He received a PhD in computer science from Carnegie Mellon University and is a distinguished member of the ACM.

Ipek Ozkaya is a principal researcher at the Carnegie Mellon University Software Engineering Institute. Her primary work includes developing techniques for improving software development efficiency and system evolution, with an emphasis on software architecture practices, software economics, agile development, and managing technical debt in complex, large-scale software-intensive systems. In addition, as part of her responsibilities, she works with government and industry organizations to improve their software architecture practices. She received a PhD in Computational Design from Carnegie Mellon University. Ozkaya is a senior member of IEEE and the 20192021 editor-in-chief of IEEE Software magazine.