Extreme Software Engineering A Hands-On Approach

by Steinberg, Daniel H.; Palmer, Daniel W.

• ISBN13: 9780130473813
• ISBN10: 0130473812
• Edition: 1st
• Format: Paperback
• Copyright: 2003-10-27
• Publisher: Prentice Hall

Summary

This hands-on software engineering volume fills the gap between the way users learn to program and the way software is written in professional practice with an interactive, project-oriented approach that includes guidelines for using XP methods for software engineering , tutorials on the core aspects of XP, and detailed descriptions of what to expect when applying XP to a development project. Using methodologies that are flexible enough to meet the changing needs of future clients, the book provides a detailed description of what happens in a typical cycle during an XP development effort and shows users what to do instead of telling them what to do. The volume provides an introduction to the Core XP practices, and details pair programming, understanding why we test first, the iteration, shaping the development process and core practices and working examples of core practices. For software engineers, developers, and programmers , and managers who want to learn about XP.

Author Biography

Daniel N. Steinberg has taught at Case Western Reserve University, Oberlin College, and John Carroll University where he introduced courses in Java^™, Design Patterns, and XP. He is the director of Java Offerings at Dim Sum Thinking. A developer, trainer, and consultant, he has been teaching and writing about Java since 1996. Daniel has covered Java on the Macintosh^® for the O'Reilly Network's^™ MacDevCenter and for JavaWorld magazine. In addition to contributing to four previous computer science books, Daniel has also written articles and tutorials for the developer sites at Sun, IBM, BEA, and Apple.

Daniel W. Palmer is an associate professor at John Carroll University where he has been teaching Software Engineering and Computer Science for eight years. He worked at NASA as a software engineer on many satellite missions including as project leader for Cosmic Background Explorer (COBE) satellite telemetry software development at Goddard Space Flight Center. Currently, he is the director of the Swarm Research Laboratory at John Carroll University, investigating swarm intelligence and emergent behavior.

Table of Contents

Acknowledgments	xxiii
Introduction---Previewing the Road Ahead	1	(1)
Software Engineering	1	(3)
Building Bridges	2	(1)
There Is No ``Software Physics'' Supporting Software Engineering	2	(1)
Tending Gardens	3	(1)
A ``Hands-on'' Software-Engineering Course	4	(2)
Course-Long Project	5	(1)
Outside Independent Client	5	(1)
Origin of the Hands-on Software-Engineering Course	6	(2)
Traditional Software Development	6	(1)
Organization of the Team	7	(1)
Extreme Programming	8	(4)
Learning XP	9	(1)
The Practices of Extreme Programming	10	(2)
Integrating XP and a Hands-on Software-Engineering Course	12	(3)
PART I THE SPIKE---GETTING UP TO SPEED	15	(52)
The Metaphor---Developing a Sense of Where We're Headed	17	(8)
Writing the Syllabus	17	(1)
First Things First	18	(1)
The Waterfall Method	19	(1)
Limitations of the Modified Waterfall	19	(4)
Unanswerable Questions	20	(1)
Building Estimates on No Data	20	(1)
The Life of the Project	21	(1)
What Happened?	22	(1)
Back to the Classroom	23	(1)
Software Engineering Approaches	24	(1)
Last Things First	24	(1)
Getting Started---Introducing the Core XP Practices	25	(10)
main ()	26	(1)
Spikes---A Quick Investigation	27	(1)
An XP Spike to Learn the Basic XP Practices	28	(4)
User Stories	29	(1)
Estimates	29	(1)
Living with Set Priorities	29	(1)
Pairing	30	(1)
Testing First	30	(1)
Continuous Design Improvement	31	(1)
Synergies	31	(1)
We Need to Do This before That	32	(1)
The Customer Makes the Business Decisions	32	(1)
Choosing an XP Spike	33	(2)
Pair Programming---Learning to Work Together	35	(16)
Roles in Pairing	36	(2)
The Driver	37	(1)
The Copilot	37	(1)
Good Things Happen in Pairs	38	(1)
A Tale of Two Pairings	38	(1)
Two Heads Are 1.7 Times Better than One	38	(1)
Benefits of Pair Programming	39	(4)
Real-Time Code Reviews	39	(1)
Avoiding Distractions	40	(1)
Managing for Two	41	(2)
Knowledge and Information Migration	43	(1)
Pairing in Practice---Dealing with Practical Issues	43	(4)
The Third Alternative	44	(1)
The Pair	44	(1)
Groups of Pairs	44	(1)
Learning by Watching and Doing	45	(1)
Reading Each Other's Signals	45	(1)
Giving Up the ``Wheel''	45	(1)
Font Size and Eyesight	46	(1)
Code Formatting	46	(1)
Revision Control	46	(1)
Mixing and Matching	47	(1)
Scheduling Time to Pair	47	(1)
A Final Word on Pairing	47	(1)
Pair Programming Exercises	47	(4)
First Test, Then Code---Understanding Why We Test First	51	(16)
How Can You Test First? There's Nothing to Test	52	(5)
Writing a Test Case	52	(1)
Passing the Test	53	(1)
What's an Alternative to Exhaustive Testing?	54	(2)
``Test First'' Really Does Mean ``Code Afterwards''	56	(1)
Developing a Test Suite	56	(1)
Automated Testing	57	(1)
Testing First Helps You Write Better Code	57	(4)
Testing First Forces Simplicity	57	(1)
Simplicity Drives the Design	58	(1)
Testing First Clarifies the Task at Hand	59	(1)
Testing First Frees You from On-the-Fly Editing	59	(1)
Test Suites Make Refactoring Possible	60	(1)
Testing First Makes Sense	60	(1)
Test Suite Maintenance	61	(1)
Fixing Broken Test Cases	61	(1)
Adding Missing Tests	62	(1)
Test Suites Considered Helpful---To the Team's Frame of Mind	62	(1)
The Psychological Benefits of Green	63	(1)
The Psychological Benefits of Red	63	(1)
Testing First Exercises	63	(4)
PART II THE ITERATION---SHAPING THE DEVELOPMENT PROCESS	67	(60)
The Client---Meeting Another Team Member	69	(14)
The Client's Job	70	(1)
How Is This Client Different from ``Real'' Clients?	71	(4)
Investment	72	(1)
Commitment	72	(1)
Relationship	73	(1)
Pace and Decisions	74	(1)
The Planning Game	75	(8)
Meeting to Determine User Stories	75	(1)
Analysis and Estimation	76	(1)
Determining Your Workload	77	(1)
Reevaluating and Prioritizing the User Stories	78	(1)
Choosing and Estimating Tasks	78	(1)
Dealing with Disappointment	79	(1)
The End of the First Iteration	80	(1)
Rinse and Repeat	81	(2)
The Plans---Beginning an Iteration	83	(10)
Kicking Off Every Iteration	84	(2)
Taking Stock of Where You Are	85	(1)
Breaking Down Tasks	86	(3)
Working Plans	86	(1)
Communication Plans	87	(1)
Integration Plans	88	(1)
The First Iteration	89	(4)
Installing Software	89	(1)
First Estimates	90	(1)
Coding Conventions	91	(2)
The Values, Principles, and Practices---Living the Iteration	93	(12)
The Core of the Iteration	93	(2)
Problems That Arise	95	(5)
Do We Really Have to Pair Program?	95	(1)
No All Nighters	96	(2)
The Simplest Thing Isn't Obvious	98	(1)
Hey, That's My Code	99	(1)
The Larger View of XP	100	(5)
Values	101	(2)
Principles	103	(2)
Acceptance Tests---Determining that a Story is Completed	105	(12)
Aren't We Testing Already?	106	(1)
Running Acceptance Tests	107	(1)
Understanding the Tests	108	(3)
Writing the Tests	111	(2)
Automating the Tests	113	(3)
Using a Custom Framework	113	(2)
The Fit Framework	115	(1)
Exercise	116	(1)
Evaluation and Regrouping---Wrapping Up an Iteration	117	(10)
Finishing Up Each Iteration	117	(1)
Run Acceptance Tests	118	(1)
Assess What Was Completed	119	(1)
Discuss Problems That Came Up	119	(1)
Budget for the Next Iteration	120	(1)
Estimate User Stories	121	(1)
Deliver to the Client	122	(1)
Plan with the Client	123	(1)
Completing the Last Iteration	123	(1)
Include the Wrap Up in Your Estimates	124	(1)
Assess Where You Are	124	(1)
Prepare the Final Presentation	124	(1)
Prepare the Final Installation	124	(3)
PART III CORE PRACTICES---WORKING EXAMPLES OF CORE PRACTICES	127	(118)
Test First---Learning a New Way of Life	129	(22)
Overview of Testing First	129	(2)
The Rules of Life	131	(1)
Setting Up JUnit	132	(2)
Setting Up the Infrastructure	132	(1)
Running a Suite	133	(1)
Creating Your First Test	134	(4)
Extending TestCase	134	(1)
Where Do Tests Come From?	135	(1)
Writing Your Test	135	(1)
Getting It to Compile	136	(1)
Getting It to Pass	136	(1)
Look Around for Refactoring	137	(1)
Writing More Tests	138	(3)
Checking for Changes in Live Cells	138	(2)
Check for Changes in Dead Cells	140	(1)
What You Don't Have	141	(1)
Allowing Cells to Change	141	(3)
The Test Cases	142	(1)
Refactoring	143	(1)
Testing GUIs	144	(6)
A Second Extension to TestCase	144	(1)
Tests for Cell's GUI	145	(2)
Testing Communication from Cell to CellPanel	147	(1)
Testing Communication from CellPanel to Cell	148	(2)
A Look Back	150	(1)
Exercises	150	(1)
User Stories---Exploring with the Customer	151	(14)
Before the First Meeting	152	(1)
Writing Your First User Story	153	(2)
Taking Stock of Artifacts	153	(1)
Write a User Story	154	(1)
Story Gathering	155	(2)
Find a Starting Point	155	(1)
Following a Path	155	(1)
Going Too Far	156	(1)
Getting Back on Track	157	(3)
Exploring Time Slots	157	(2)
Courses and Sections	159	(1)
Wrapping Up with the Client	160	(4)
Stopping the Client	161	(1)
Ordering the Stories	161	(1)
Preparing the Client for Reality	161	(3)
Client Variations	164	(1)
The Planning Game---Negotiating the Future	165	(18)
The Beginning User Stories	168	(2)
Refining the User Stories	170	(4)
Selecting User Stories for the First Iteration	174	(3)
The Client Provides a Basic Ordering of Stories	174	(1)
The Developers Provide Rough Estimates of the Stories	175	(1)
The Client Chooses the Current Iteration	176	(1)
A Closer Look at the Estimates	177	(4)
The Developers Break the Stories into Tasks	177	(2)
The Developers Estimate the Tasks	179	(2)
Reality Check	181	(2)
Moving from One Iteration to Another	181	(2)
Refactoring---Sharpening Your Knife	183	(14)
Example Application the Tetris Game	184	(1)
Duplicated Code	185	(4)
Example: In a Single Method	185	(3)
Example: In Two Classes	188	(1)
Almost Duplicated Code	189	(3)
Example: In Different Methods of One Class	190	(1)
Example: In Two Classes	190	(2)
What's in a Name	192	(2)
Splitting Long Methods	194	(2)
Final Thoughts	196	(1)
Customer Written Tests---Automating the Acceptance Process	197	(34)
The Fit Framework	198	(4)
Writing Acceptance Tests as HTML Tables	198	(1)
Supporting the HTML Tables with Fixtures	199	(1)
Writing the Code to Pass the Tests	200	(1)
Running Acceptance Tests with Fit	200	(1)
Exploring Fit	201	(1)
From User Stories to Acceptance Tests	202	(2)
Our First Example User Story	202	(1)
Initial Acceptance Tests for the Case Discount Story	202	(2)
Benefits of Having Acceptance Tests	204	(1)
Formalizing the Acceptance Tests	204	(15)
Mapping to the Fixture	204	(3)
Running the Tests	207	(1)
Creating a Stub Fixture	208	(3)
Writing the Production Code	211	(2)
Tying the Fixture to the Production Code	213	(1)
Passing More Acceptance Tests	213	(3)
The Client and the Acceptance Tests	216	(3)
Testing GUIs	219	(7)
Designing the Acceptance Tests	220	(1)
Stubbing Out a Fixture for the Tests	221	(1)
Problems Passing the Acceptance Tests	222	(2)
The Revised Fixture and Production Code	224	(2)
Running All of the Tests	226	(5)
The All Files Fixture	226	(1)
Results of Running the All Files Fixture	227	(1)
Next Steps	228	(3)
Development Mechanics---Organizing Your Project	231	(14)
Packages	231	(4)
A Two Class Example	232	(1)
Adding a Main Class	233	(1)
A Sample Hierarchy	234	(1)
Preparing Your Files for a Release	235	(2)
Separating Source and Class Files	236	(1)
Jar-ing Up the Results	236	(1)
Packaging Your Unit Test Files	237	(3)
The Tests	237	(2)
Separating the Test Files	239	(1)
JavaDocs	240	(2)
The Various Builds	242	(3)
Integrating Code	242	(1)
Distribution Checklist	243	(1)
Automating the Build	244	(1)
APPENDIX A EXPERIENCE IN THE TRENCHES---SHARING USER STORIES	245	(8)
APPENDIX B FOR PROFESSIONALS---CUSTOMIZING THE COURSE	253	(10)
Training Workshop	253	(4)
The Compressed Spike	254	(1)
A Three-day Project	255	(1)
A Postmortem Discussion	256	(1)
Self-Paced Self-Taught Practicum	257	(6)
Learning with a Partner	257	(2)
An Individualized Approach	259	(4)
References	263	(2)
Index	265

Excerpts

At some point in the process of learning the craft of software development, you need to work on a real project for a real client. The project must be large enough that you can't hold all of the details in your head. The duration of the project must be long enough that you don't remember what you were intending when you wrote the code that you later are trying to understand. The project must be complex enough that you need to clarify requirements that you thought you once understood. Many colleges and universities offer a one- or two-term course in which the students learn about software engineering by working on a significant project for a real client. We don't claim to have invented this idea. Our version of a hands-on software engineering class is derived from the course created by Fred Brooks at Chapel Hill. Students work on a real project for a real client while spending class time discussing readings on various software methodologies and on issues that can arise during the students' practical experience. eXtreme Programming (XP) is well suited to the academic setting. Initially, and for several years, software teams in our course used the traditional approach. They worked their way from requirements' analysis to final delivery over the course of a semester. One semester half of the class continued with the traditional approach and half of the class used XP The course now runs with all of the software teams using XP as their methodology for these practicums. The pedagogical benefits of using XP were immediately clear. Students that work in small groups get consistent and useful feedback about their progress. This comes from other students they pair with, from seeing the unit-tests pass, from completing tasks, and from quick and frequent client reaction. All students communicate with clients, coaches, "bosses," and each other. No skill is as important as communication. The students are constantly required to communicate verbally and through their code and other writing. Students begin to see, how various pieces fit together. Instead of working on toy programs intended to illustrate a particular point such as sorting, students see how they and others on the same project are dependent on the sorting code they've written. HANDS-ON SOFTWARE ENGINEERING There is a gap between the way students learn to program in an academic setting and the way software is written in professional practice. Some of the differences result from the differing goals of the two environments: computer science departments aim to teach the craft of programming, and professional software developers set out to create useful programs. Students are learning the craft, so they can focus on one thing at a time; professionals must deal with a myriad of factors simultaneously. The larger the gap grows the more additional training students need after graduation. Academia is faced with the task of being more relevant to students without becoming a purely vocational venue. Certification programs exist, and do provide useful, short-term value, but because of the blazingly fast refresh rate of technology, students who choose this route sacrifice building a general, far-reaching foundation. The simple fact is that the specifics of a given platform, package, or language covered during the four years of college may very well be outdated by graduation. Today's language syntax or operating system (OS) features have little more staying power than a passing fad or a moderately popular sitcom. Instead, students must develop an understanding of the trade-offs, the issues, and the broader context that will shape "next thing" and "the thing after that." This book describes a course that begins to bridge the gap between academic and professional software practices. It describes how to build an environment within the academic crucible that more closely mirrors the pressures, constraints, and interdependencies of a realistic soft