Skip to main content

Currently Skimming:

Interactive Survey Development: An Integrated View
Pages 164-173

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 164...
... He is currently a technology transfer consultant at the NASA Ames Research Center. He founded Reasoning, Inc., and was for several years the product manager for their principal product, which was a tool for automated software defect detection.
From page 165...
... We don't want to have particularly if there's a hard deadline everybody spending a lot of time initially doing requirements analysis and then, you lcnow, design and implementation. And then, at the end, we find that we send it over the fence and the customer rejects it because of a requirements issue that could have been found much earlier in the process.
From page 166...
... One of the requirements for doing extreme programming is a commitment by all the lcinds of people involved to work together shoulderto-shoulder. SO, we're not going to have developers sitting there doing development on their own'.
From page 167...
... And the purpose of the stand-up meeting is to avoid these long meetings, these three-hour meetings where people sit around they're very low bandwidth meetings, people fall asleep, and very little gets communicated. What we do at the beginning is have a very short meeting, with a time limit set, where all the issues are brought up, and then the development group breaks up into the natural teams to address these issues.
From page 168...
... And so we should really be trying to get the project right maybe not completely at the beginning, but certainly incrementally as you go along, refine it to the project plan. Here is a slide I promised on collective code ownership, and notice at the top here it says, "Move People Around.'' And in the center it says, "Pair Programming." So these are two of the lacy concepts we want people, the developers, to adopt any role in the project, work on any component of the project.
From page 169...
... OIL, so that's my perspective on the integrated development process; now, let's talce a look at some integrated toolsets that can help with some aspects of the development, with many aspects of the development. OIL, first of all, what we want to do using integrated tools is first capture, formal capture, of logical artifacts.
From page 170...
... CAI seems to be particularly amenable to finite state modelling, so there are within UML tools that allow you to model state machines using state diagrams. And then there are ways of modelling component relationships (the components of your software systems are the source code packages and their relations)
From page 171...
... There's been a lot of discussion of state machines, and the state charts are a way of representing state machines. They have several advantages over simply drawing the complete finite state machine, which may in fact have too many states to even be drawn.
From page 172...
... This is quite different from drawing a Microsoft Project document and then trying to plot where you are along the way to meeting milestones. Collective ownership enhances understanding among participants, and automated generation of software artifacts, again, imports this notion of risk reduction by allowing the project history to be captured and preventing loss of information.
From page 173...
... DOYLE: One of the things that we had done was to have people specialize in a particular survey, and often you end up with one programmer on a complicated survey. But a lot of these testing things might suggest that we need teams; we need more than one on a project.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.