Software Engineering With Microsoft Visual Studio Team System

by Guckenheimer, Sam; Perez, Juan J.

• ISBN13: 9780321278722
• ISBN10: 0321278720
• Edition: 1st
• Format: Paperback
• Copyright: 2006-01-01
• Publisher: Addison-Wesley Professional

Summary

The definitive introduction to Microsoft's new suite of software development tools, direct from the lead developer.

Author Biography

Sam Guckenheimer is the group product planner for Microsoft Visual Studio Team System

Table of Contents

About the Author	xvii
Foreword	xix
Preface	xxi
Acknowledgments	xxix
A Value-Up Paradigm	1	(26)
A Paradigm Shift	2	(2)
Three Forces to Reconcile	2	(1)
What Software Is Worth Building?	3	(1)
Contrasting Paradigms	4	(4)
Attention to Flow	8	(5)
Contrast to Work-Down	10	(1)
Transparency	11	(2)
One Work Item Database	13	(8)
Instrument Daily Activities	17	(4)
Fit the Process to the Project	21	(1)
Summary	22	(1)
Endnotes	23	(4)
Value-Up Processes	27	(22)
Microsoft Solutions Framework	28	(2)
Iteration	30	(6)
Why Iterate?	30	(2)
Length	32	(1)
Different Horizons, Different Granularity	33	(1)
Prioritization	33	(2)
Adapting Process	35	(1)
Risk Management	36	(1)
Fit the Process to the Project	37	(9)
Adaptive Versus Plan-Driven	38	(1)
Required Documentation Versus Tacit Knowledge	39	(1)
Implicit Versus Explicit Sign-Off Gates and Governance Model	40	(1)
Auditability and Regulatory Concerns	41	(2)
Prescribed Versus Self-Organization	43	(1)
One Project at a Time Versus Many Projects at Once	43	(2)
Geographic and Organizational Boundaries	45	(1)
Summary	46	(1)
Endnotes	47	(2)
Requirements	49	(30)
What's Your Vision?	50	(2)
Strategic Projects	51	(1)
Adaptive Projects	51	(1)
When to Detail Requirements	52	(3)
Requirements Are Perishable	52	(1)
Who Cares About Requirements	53	(2)
Personas and Scenarios	55	(10)
Start with Personas	55	(1)
Scenarios	56	(1)
Research Techniques	57	(2)
Get Specific Early	59	(1)
Storyboards	60	(1)
Breadth of Scenarios	61	(1)
Customer Validation	62	(2)
Evolving Scenarios	64	(1)
Personas and Scenarios and Their Alternatives	65	(1)
Actors and Use Cases	65	(1)
User Stories	66	(1)
Exciters, Satisfiers, and Dissatisfiers	66	(1)
Qualities of Service	67	(4)
Security and Privacy	68	(1)
Performance	68	(1)
User Experience	69	(1)
Manageability	70	(1)
Kano Analysis	71	(4)
Technology Adoption Lifecycle	73	(1)
Gathering the Data	74	(1)
Summary	75	(1)
Endnotes	76	(3)
Project Management	79	(36)
Understanding Variation	81	(2)
Using Descriptive Rather Than Prescriptive Metrics	83	(3)
Many Dimensions of Project Health	86	(1)
Answering Everyday Questions	86	(12)
Remaining Work	88	(2)
Project Velocity	90	(1)
Unplanned Work	91	(1)
Quality Indicators	92	(1)
Bug Rates	93	(2)
Reactivations	95	(1)
Bugs by Priority	95	(2)
Actual Quality Versus Planned Velocity	97	(1)
Estimating an Iteration	98	(6)
Top-Down	99	(1)
Bottom-Up	100	(1)
Refinements	100	(2)
Estimation Quality	102	(1)
Retrospectives	103	(1)
Triage	104	(5)
A Triage Exercise	104	(2)
What Makes Triage Effective: The Red Line	106	(2)
What Happens During Triage	108	(1)
Escalating and Resolving Issues	108	(1)
Iterations and Triage	108	(1)
Satisfying the Auditor	109	(3)
Summary	112	(1)
Endnotes	112	(3)
Architectural Design	115	(18)
A Value-Up View of Architecture	116	(1)
Service-Oriented Architecture	116	(3)
Web Services and SOA	118	(1)
Contract-First Design	118	(1)
Constraints with Degrees of Freedom	119	(5)
Baseline Architecture	119	(2)
Validate Architectural Decisions	121	(1)
Refining the Baseline	121	(1)
Reference Architectures	122	(2)
VSTS and Service-Oriented Architecture	124	(2)
Quality of Service Mindset	126	(2)
Security	127	(1)
Performance	127	(1)
Citizenship Mindset	128	(1)
Design for Operations	128	(3)
Summary	131	(1)
Endnotes	131	(2)
Development	133	(32)
A Value-Up View of Development	134	(1)
Quality from a Developer's Point of View	134	(2)
Using Test-Driven Development to Ensure Requirements Clarity	136	(2)
Addressing Programming Errors with Code Reviews, Automated and Manual	138	(3)
Automated Code Analysis	139	(1)
Manual Code Reviews	140	(1)
Providing Immediate Feedback with Unit Tests and Code Coverage	141	(4)
Test First or Code First?	142	(1)
Code Coverage	143	(2)
Making Unit Tests Better	145	(7)
Using Data	146	(1)
Configurations	146	(1)
Component Integration Tests	147	(1)
Build Verification Tests	148	(1)
Turning Performance	149	(3)
Preventing Version Skew	152	(8)
Checking In	153	(2)
Shelving	155	(1)
Branching	156	(1)
What to Version	156	(1)
Automating the Build	156	(4)
Making Work Transparent	160	(2)
Summary	162	(1)
Endnotes	163	(2)
Testing	165	(40)
A Value-Up View of Testing	166	(3)
What Makes a Good Tester?	167	(2)
Basic Questions	169	(1)
Are We Delivering the Customer Value?	169	(8)
Automated Scenario Tests	172	(4)
Insulating Your Tests from UI Changes	176	(1)
Are the Qualities of Service Fit for Use?	177	(6)
Load Testing	177	(5)
Security Testing	182	(1)
Usability Testing	183	(1)
Have We Tested the Changes?	183	(1)
What Haven't We Tested?	184	(5)
Requirements	184	(2)
Code	186	(1)
Risks	187	(2)
Does It Work in Production as Well as in the Lab?	189	(3)
Are We Testing Enough?	192	(4)
Defining ``Good Enough''	192	(2)
Exploratory Testing	194	(1)
Testing as Discovery	194	(1)
False Confidence	195	(1)
When Should We Test?	196	(5)
Check-In Cycle	196	(1)
Daily Build Cycle	196	(2)
Accepted Build Cycle	198	(1)
Iteration Cycle	199	(1)
Project Cycle	200	(1)
Which Tests Should Be Automated?	201	(1)
How Efficient Is Our Team, Or Our Outsourced Team?	201	(1)
Summary	202	(1)
Endnotes	203	(2)
Reporting Bugs	205	(16)
A Cautionary Tale	207	(1)
A (Software) Bug's Life	208	(10)
Bug Reporting Is Like Journalism	210	(3)
Subjective Data	213	(1)
Objective Data	214	(2)
Assessment Data	216	(2)
Plan	218	(1)
Summary	218	(1)
Endnotes	219	(2)
Troubleshooting the Project	221	(22)
Underestimating	223	(6)
Uneven Task Decomposition	224	(1)
Architectural Blind Spots	224	(3)
Scope Creep	227	(2)
Inadequate Bug Allotment	229	(1)
Resource Leaks	229	(1)
Development Practices Too Loose	229	(4)
Build Failures	229	(2)
Inadequate Unit Testing	231	(1)
Reactivations	232	(1)
Bluffing	233	(1)
Tests Passing; Solution Doesn't Work	233	(3)
High Bug Find Rate	233	(3)
Tests Are Stale	236	(1)
Solution Stuck in Testing	236	(4)
Tests Failing	237	(1)
Too Little Testing	238	(2)
Summary	240	(1)
Endnotes	241	(2)
Conclusion	243	(6)
Expected Criticisms	244	(1)
Value-Up, Again	245	(2)
Endnotes	247	(2)
Index	249

Excerpts

= 0) {slash = '\\';} else {slash = '/';}openLoc = figLoc.substring(0, figLoc.lastIndexOf(slash) + 1);while (pPage.substring(0,3) == '../') {openLoc = openLoc.substring(0, openLoc.lastIndexOf(slash, openLoc.length - 2)+ 1);pPage = pPage.substring(3, pPage.length + 1);}popUpWin =window.open('','popWin','resizable=1,scrollbars=1,location=0,toolbar=0,width=525,height=394');figDoc = popUpWin.document;zhtm= ' ' + pPage + ' ';zhtm += ' ';zhtm += ' ';zhtm += ' ';zhtm += '' + pPage.substring(pPage.lastIndexOf('/') + 1, pPage.length) + '';zhtm += ' ';figDoc.write(zhtm);figDoc.close();}// modified 3.1.99 RWE v4.1 --> Preface Preface Why I Wrote This BookI joined Microsoft in 2003 to work on Visual Studio Team System (VSTS), the new product line that was just released at the end of 2005. As the group product planner, I have played chief customer advocate, a role that I have loved. I have been in the IT industry for twenty-some years, spending most of my career as a tester, project manager, analyst, and developer.As a tester, I've always understood the theoretical value of advanced developer practices, such as unit testing, code coverage, static analysis, and memory and performance profiling. At the same time, I never understood how anyone had the patience to learn the obscure tools that you needed to follow the right practices.As a project manager, I was always troubled that the only decent data we could get was about bugs. Driving a project from bug data alone is like driving a car with your eyes closed and only turning the wheel when you hit something. You really want to see the right indicators that you are on course, not just feel the bumps when you stray off it. Here too, I always understood the value of metrics, such as code coverage and project velocity, but I never understood how anyone could realistically collect all that stuff.As an analyst, I fell in love with modeling. I think visually, and I found graphical models compelling ways to document and communicate. But the models always got out of date as soon as it came time to implement anything. And the models just didn't handle the key concerns of developers, testers, and operations.And in all these cases, I was frustrated by how hard it was to connect the dots for the whole team. I loved the idea in Scrum (one of the agile processes) of a "single product backlog"--one place where you could see all the work--but the tools people could actually use would fragment the work every which way. What do these requirements have to do with those tasks, and the model elements here, and the tests over there? And where's the source code in that mix?From a historical perspective, I think