Extreme Software Engineering : Hands-On Approach / Edition 1

Paperback (Print)
Buy Used
Buy Used from BN.com
$40.00
(Save 41%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 97%)
Other sellers (Paperback)
  • All (16) from $1.99   
  • New (6) from $40.80   
  • Used (10) from $1.99   

Overview

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.

Read More Show Less

Product Details

  • ISBN-13: 9780130473813
  • Publisher: Prentice Hall
  • Publication date: 10/27/2003
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 304
  • Product dimensions: 7.00 (w) x 8.97 (h) x 0.78 (d)

Meet the Author

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.

Read More Show Less

Read an Excerpt

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, fromseeing 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 software development effort. It uses methodologies that are flexible enough to meet the changing needs of clients within the rigid time constraints of an academic calendar. But eXtreme Programming is more than just a schedule management tool, it promotes good programming practices, it improves the quality of the produced code, and it helps integrate a group of individual programmers into a development team. In short, it's more than just a way to program, it's a great way to teach software engineering. WHO IS THIS BOOK FOR?

This book is particularly well suited to be used in three settings.

  1. A project-based class in computer science where the students work in groups on long-term (one quarter/one semester or more) projects for actual clients.
  2. A team of developers interested in an immersive experience to investigate eXtreme Programming.
  3. One or more developers planning a self-directed exploration of the principles and practices of eXtreme Programming.
Academic Settings

This book is primarily aimed at supporting an extended programming experience. The usual audience consists of established undergraduate computer science majors, with many semesters of computer science courses behind them. This course can serve as a capstone experience, and, as such, requires that students have a solid and varied collection of programming experience. Though it is not required for this course specifically or for software engineering in general, this book assumes an understanding of object-oriented programming, and in particular, the Java programming language.

This book is not intended to be a comprehensive introduction to software engineering. This book provides instruction, guidance, and examples in the experiential component of the class. Instructors will need to select a traditional software-engineering textbook or supplemental readings to cover methods from other Agile or traditional methodologies. As this landscape is always changing, we use supplemental readings as the basis for in-class discussions. Professional Training Settings

A weeklong immersive experience using XP will give you the flavor of the methodology and enough experience to jump start an XP project in your work environment. In that setting, this book can be used as a valuable reference so that you can prepare for the training by reading the chapters in the Parts I and II to prepare for the training experience. You can then read the chapters in the Part III after the training week to supplement your understanding of the core practices. Self-Study Groups or Individuals

For teams of software developers, the book provides you with a concrete look at the practices and of the life cycle of an iteration. In addition there are tutorial chapters designed to lead you step-by-step through the application of practices. The level of detail should support you and your group while studying this material on your own. Although pair programming is one of the central programming practices of XP, constraints may not allow you to explore XP with others. In this case you can still use this book as a study guide, but you should look for opportunities to try out pair programming. FEATURES OF THE BOOK

Some of the book's features that support this interactive, project-oriented approach include: guidelines for setting up and presenting an XP software-engineering course (including an intense introduction to all the features of XP), a collection of tutorials on the core aspects of XP, a detailed description of what to expect each week when applying XP to a development project, and feedback from students, faculty, and clients who have been through the process.

The centerpiece of the book is the collection of practical tutorials that allow the reader to learn by doing the key XP practices. The tutorials provide step-by-step instruction on test-driven design, refactoring code, writing and running acceptance tests, interacting with the client, and using XP's planning game to determine where the development should focus its energy. Even if the reader unfamiliar with XP does nothing other than work through the tutorials, he or she will get the essence of what it is to work on an eXtreme Programming development effort.

For a fuller and more detailed portrait, the book offers a broader view of XP and how it integrates into a software-engineering course. In particular, the book provides a detailed description of what happens during a typical XP development effort. From the first interaction with the client, to ongoing meetings and programming sessions with fellow XP developers, through the conclusion of the project, this book describes in detail the activities, expectations, and responsibilities of all the participants in the process. NOTE TO INSTRUCTORS

When a practical experience is the centerpiece to your course there are two basic approaches. In the first, you can take time to teach each of the practices or skills that the student will encounter before they encounter it. There are courses in traditional software engineering that do this. You lecture about creating a requirements document and then you have the students create one. A second approach is to get the students immersed in the programming experience as quickly as possible. The arguments for each of these approaches mirror the arguments for big up-front design versus the extreme just-in-time design.

We recognize the value in each of these approaches and have designed this book to meet some of the requirements of each. The fear that the up-front learning advocates have is that there are topics that may not be covered in the second approach. The extreme teaching crowd worries that the first approach spends a lot of time on concepts that the students don't know they need yet. This is not quite the you aren't going to need it (YAGNI) rule of XP This is more that you don't know that you are going to need it. In teacher-training classes, future teachers are taught six different ways of asking questions and about different learning styles. They nod their heads and pass tests, but until they stand in front of their own class, they don't understand the relevance of the material.

You can cover the material in Part I to prepare the students for their practical experience. We suggest a Spike—a small practice project designed to get some of the kinks out before the actual project begins. Part II explains the shape of the iteration to the students. They need to read Part II before beginning their actual long-term project. Part III can be used in two ways, depending on whether you're taking the just-in-time or the up-front approach. You can either use these tutorials to cover and explain each of the practices before the students engage in them or you can leave them to the students to explore when they recognize the need. The remainder of the text contains information that doesn't need to be imparted to the student at any particular time. NOTE TO STUDENTS

Most of the valuable learning from this book will come when you put it away for a while and work on exercises, step through tutorials, or try out a practice.

You can't learn Tai Chi sitting down, you can't learn to ski from the warmth of the lodge, and you can't learn to build large software systems using an Agile® methodology without ,booting up the computer. This book is designed for use in conjunction with an actual software development effort. The text shows you what to do instead of telling you what to do.

You will have a client. You'll find chapters that describe how to work with the client throughout the lifetime of the project. You'll work with a team. Much of the material in this book will help you negotiate with the team to figure out what is going to be done next and by whom. All of your code will be written in pairs. Pair programming may seem to fly in the face of how you've worked so far, but take this opportunity to give it a try. The biggest changes you will be asked to make are in how you actually write your code. You will be led through the process of writing test first code and looking for ways to improve it. As you need them, read and follow the tutorials on some of the more central practices.

Don't get too caught up in the details. XP is just a methodology. The goal in this course is to engage in all of the facets of software development. You will work with customers to elicit and focus requirements. You will design and build software. You will release your software and present your work to the customer. With XP you will pass through these steps many times during the semester. Each time, take a moment to note what you are learning and what you can do to make the next time through the XP process even better. NOTE TO PROFESSIONALS

The advice in the "Note to Students" section applies to you too. In addition, you will find an outline in the second appendix of how you might organize the material depending on whether you are organizing a self-directed study group or a formal training workshop.

The easiest way to learn a new programming language, technique, or methodology is to choose a real project on which to experiment. With XP, it is even better to have an independent customer to interact with. It could be a real client, a friend, or relative. In a pinch you can be your own client—just be clear to keep separate when you are making decisions as the client and when you are making decisions as the developer.

The final request is that you give XP a fair trial. When you are a student in a formal course you will have to commit to XP for the duration of the course. With self-study or following a short-term immersion you can give up on XP before you realize the benefits. Writing code test first may feel like an added burden until the first time you have to perform a major refactoring and the unit tests protect you.

Read More Show Less

Table of Contents

I. THE SPIKE—GETTING UP TO SPEED.

1. The Metaphor—Developing a Sense of Where We're Headed.

2. Getting Started—Introducing the Core XP Practices.

3. Pair Programming—Learning to Work Together.

4. First Test, Then Code—Understanding Why We Test First.

II. THE ITERATION—SHAPING THE DEVELOPMENT PROCESS.

5. The Client—Meeting Another Team Member.

6. The Plans—Beginning an Iteration.

7. The Values, Principles and Practices—Living the Iteration.

8. Acceptance Tests—Determining That a Story is Completed.

9. Evaluation and Regrouping—Wrapping Up an Iteration.

III. CORE PRACTICES—WORKING EXAMPLES OF CORE PRACTICES.

10. Test First—Learning a New Way of Life.

11. User Stories—Exploring with the Customer.

12. The Planning Game—Negotiating the Future.

13. Refactoring—Sharpening Your Knife.

14. Customer Written Tests—Automating the Acceptance Process.

15. Development Mechanics—Organizing Your Project.

Read More Show Less

Preface

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 software development effort. It uses methodologies that are flexible enough to meet the changing needs of clients within the rigid time constraints of an academic calendar. But eXtreme Programming is more than just a schedule management tool, it promotes good programming practices, it improves the quality of the produced code, and it helps integrate a group of individual programmers into a development team. In short, it's more than just a way to program, it's a great way to teach software engineering.

WHO IS THIS BOOK FOR?

This book is particularly well suited to be used in three settings.

  1. A project-based class in computer science where the students work in groups on long-term (one quarter/one semester or more) projects for actual clients.
  2. A team of developers interested in an immersive experience to investigate eXtreme Programming.
  3. One or more developers planning a self-directed exploration of the principles and practices of eXtreme Programming.

Academic Settings

This book is primarily aimed at supporting an extended programming experience. The usual audience consists of established undergraduate computer science majors, with many semesters of computer science courses behind them. This course can serve as a capstone experience, and, as such, requires that students have a solid and varied collection of programming experience. Though it is not required for this course specifically or for software engineering in general, this book assumes an understanding of object-oriented programming, and in particular, the Java programming language.

This book is not intended to be a comprehensive introduction to software engineering. This book provides instruction, guidance, and examples in the experiential component of the class. Instructors will need to select a traditional software-engineering textbook or supplemental readings to cover methods from other Agile or traditional methodologies. As this landscape is always changing, we use supplemental readings as the basis for in-class discussions.

Professional Training Settings

A weeklong immersive experience using XP will give you the flavor of the methodology and enough experience to jump start an XP project in your work environment. In that setting, this book can be used as a valuable reference so that you can prepare for the training by reading the chapters in the Parts I and II to prepare for the training experience. You can then read the chapters in the Part III after the training week to supplement your understanding of the core practices.

Self-Study Groups or Individuals

For teams of software developers, the book provides you with a concrete look at the practices and of the life cycle of an iteration. In addition there are tutorial chapters designed to lead you step-by-step through the application of practices. The level of detail should support you and your group while studying this material on your own. Although pair programming is one of the central programming practices of XP, constraints may not allow you to explore XP with others. In this case you can still use this book as a study guide, but you should look for opportunities to try out pair programming.

FEATURES OF THE BOOK

Some of the book's features that support this interactive, project-oriented approach include: guidelines for setting up and presenting an XP software-engineering course (including an intense introduction to all the features of XP), a collection of tutorials on the core aspects of XP, a detailed description of what to expect each week when applying XP to a development project, and feedback from students, faculty, and clients who have been through the process.

The centerpiece of the book is the collection of practical tutorials that allow the reader to learn by doing the key XP practices. The tutorials provide step-by-step instruction on test-driven design, refactoring code, writing and running acceptance tests, interacting with the client, and using XP's planning game to determine where the development should focus its energy. Even if the reader unfamiliar with XP does nothing other than work through the tutorials, he or she will get the essence of what it is to work on an eXtreme Programming development effort.

For a fuller and more detailed portrait, the book offers a broader view of XP and how it integrates into a software-engineering course. In particular, the book provides a detailed description of what happens during a typical XP development effort. From the first interaction with the client, to ongoing meetings and programming sessions with fellow XP developers, through the conclusion of the project, this book describes in detail the activities, expectations, and responsibilities of all the participants in the process.

NOTE TO INSTRUCTORS

When a practical experience is the centerpiece to your course there are two basic approaches. In the first, you can take time to teach each of the practices or skills that the student will encounter before they encounter it. There are courses in traditional software engineering that do this. You lecture about creating a requirements document and then you have the students create one. A second approach is to get the students immersed in the programming experience as quickly as possible. The arguments for each of these approaches mirror the arguments for big up-front design versus the extreme just-in-time design.

We recognize the value in each of these approaches and have designed this book to meet some of the requirements of each. The fear that the up-front learning advocates have is that there are topics that may not be covered in the second approach. The extreme teaching crowd worries that the first approach spends a lot of time on concepts that the students don't know they need yet. This is not quite the you aren't going to need it (YAGNI) rule of XP This is more that you don't know that you are going to need it. In teacher-training classes, future teachers are taught six different ways of asking questions and about different learning styles. They nod their heads and pass tests, but until they stand in front of their own class, they don't understand the relevance of the material.

You can cover the material in Part I to prepare the students for their practical experience. We suggest a Spike—a small practice project designed to get some of the kinks out before the actual project begins. Part II explains the shape of the iteration to the students. They need to read Part II before beginning their actual long-term project. Part III can be used in two ways, depending on whether you're taking the just-in-time or the up-front approach. You can either use these tutorials to cover and explain each of the practices before the students engage in them or you can leave them to the students to explore when they recognize the need. The remainder of the text contains information that doesn't need to be imparted to the student at any particular time.

NOTE TO STUDENTS

Most of the valuable learning from this book will come when you put it away for a while and work on exercises, step through tutorials, or try out a practice.

You can't learn Tai Chi sitting down, you can't learn to ski from the warmth of the lodge, and you can't learn to build large software systems using an Agile® methodology without ,booting up the computer. This book is designed for use in conjunction with an actual software development effort. The text shows you what to do instead of telling you what to do.

You will have a client. You'll find chapters that describe how to work with the client throughout the lifetime of the project. You'll work with a team. Much of the material in this book will help you negotiate with the team to figure out what is going to be done next and by whom. All of your code will be written in pairs. Pair programming may seem to fly in the face of how you've worked so far, but take this opportunity to give it a try. The biggest changes you will be asked to make are in how you actually write your code. You will be led through the process of writing test first code and looking for ways to improve it. As you need them, read and follow the tutorials on some of the more central practices.

Don't get too caught up in the details. XP is just a methodology. The goal in this course is to engage in all of the facets of software development. You will work with customers to elicit and focus requirements. You will design and build software. You will release your software and present your work to the customer. With XP you will pass through these steps many times during the semester. Each time, take a moment to note what you are learning and what you can do to make the next time through the XP process even better.

NOTE TO PROFESSIONALS

The advice in the "Note to Students" section applies to you too. In addition, you will find an outline in the second appendix of how you might organize the material depending on whether you are organizing a self-directed study group or a formal training workshop.

The easiest way to learn a new programming language, technique, or methodology is to choose a real project on which to experiment. With XP, it is even better to have an independent customer to interact with. It could be a real client, a friend, or relative. In a pinch you can be your own client—just be clear to keep separate when you are making decisions as the client and when you are making decisions as the developer.

The final request is that you give XP a fair trial. When you are a student in a formal course you will have to commit to XP for the duration of the course. With self-study or following a short-term immersion you can give up on XP before you realize the benefits. Writing code test first may feel like an added burden until the first time you have to perform a major refactoring and the unit tests protect you.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)