Survey Automation Report and Workshop Proceedings (2003) / Chapter Skim
Currently Skimming:
Software Engineering -- The Way to Be
Software Engineering -- The Way to Be
Pages 63-77
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 63... ...
We're now going to turn toward the computer science perspective, and introduce Jesse Poore, who is a professor of computer science at the University of Tennessee. POORE: You're probably wondering what a person lilac me is doing at a place, a meeting lilac this.
|
From page 64... ...
Now, I'm beginning to think based on the earlier discussion that there's some merging of software issues with survey issues. And so maybe what I'm looking at is just the software problem, and really it's the problem of the survey designs being Plunged together with some of the software problems.
|
From page 65... ...
This ~slide] is not an architecture for your product line See Figure II-24; this is a picture to let me talk about product line architectures, because I don't lcnow enough about your business to even pretend to give you i5 Specifically, Moore's Law is the popular term used to describe Intel co-founder Goraon Moore's 1965 observation that integrated circuit density or the amount of information storable on a given silicon chip doubles in magnitude every year.
|
From page 66... ...
Meanwhile, you want data movement to be totally separate from the security issue, but likewise data movement should be a matter that's comprehensive across all the platforms, all the laptops right on into the data center. The statistical analysis core of your systems shouldn't in any way be intertwined with your data movement utilities.
|
From page 67... ...
Someone in Ericsson was planning a project that was being pitched to a vice-president in Montreal, and they came up with something lily one-half million staff hours, a half million labor hours for the project. And the guy says, "We've never had in the history of Ericsson a project that was bigger than about 20O,OOO staff hours that ever succeeded.
|
From page 68... ...
lots and lots of basic tools out there to support standards, everything from project planning to configuration management and so on. I also advocate that you work in teams with peer review, so that no work product no matter what it is specification, code, test plan, anything every work product is only done when three smart people think it's right.
|
From page 69... ...
I loolced at a new system that was going into the Water Management District of Southern California, which could also be called the Los Angeles Water Company. And they were putting in a big new system to replace this mainframe with slave terminals attached to it a pretty efficient scheme.
|
From page 70... ...
You tag and trace all those decisions so that later on when yol1 find that a statistical algorithm was changed, it was changed because a statistician told you to change it not because, say, a field interviewer told you to change it. Prepare the user guides while you're writing the specs; prepare the test plans while you're writing the specs.
|
From page 71... ...
BANICS: Well, OIL. But my sense is that we have a less clear understanding of what specific legislative decisions, or judicial decisions, or executive decisions may be driven by the results of the survey.
|
From page 72... ...
I think you'll do more good with peer review of your surveys than you will in testing your surveys, particularly if yol1 develop some nice modular structure for putting them together. When yol1 were talking about all the paths through your surveys, I was thinking, "Well, there are paths through code." And, sure, there's an infinite number of paths.
|
From page 73... ...
We record all the information from the tests when we're running the tests; we monitor the progress, monitor stopping criteria. The people I work with are generally testing in order to establish or assert a certain reliability to the code, so they're monitoring the progress and stopping conditions to see when they've collected enough empirical data to malce those sorts of claims.
|
From page 74... ...
success in an organization that is typically doing good work, meeting schedules, budgets, and quality then you're doing this from the standpoint of finding out what needs to be revised about the architecture or the planning or your process or your technology or the staff, in order to do better and not to repeat those lcinds of problems. The data look sort of lilac this.
|
From page 75... ...
Yolk I mean, how are you getting motivated to get i6The Capability Maturity Model (CMM) for Software is a scale for assessing where software organizations stand in the evolutionary process from chaotic early practice to fully mature and disciplined development.
|
From page 76... ...
So that's an activity that's very, very common in software development, awfully hard to change. But when you get any organization to get onto an incremental development instead of a unit separate, unit test, and integrate they'll never go back to it, and they'll cut out that wasteful step.
|
From page 77... ...
And, according to what you've presented here, I think most of our maturity perhaps has been at the requirements and specifications development stage. Prior to automation our biggest time constraint was getting OMB's clearance at the time we were getting ready to go into the field.
|
Key Terms
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.