Software Construction
Steven J Zeil:
Abstract
The remainder of this course focuses on software construction, the collection of activities directly related to the production of working code.
We survey the component activities that make up software construction and the tools and activities that support them. Many of these tools and activities will be considered in more detail in the coming lessons.
1 Perspectives on Programming
There are many perspectives on how a “real programmer” approaches the task of developing software. Some of the biggest names in computer science and software engineering have weighed in with very different perspectives on how they themselves view the activity, and many other writers have suggested new metaphors for programming.
As you work through the readings in this section, keep alert for suggestions that…
Programming is…
-
a science (Gries)
-
an art (Knuth)
- a process (Humphries)
- like writing
- Literate Programming (Knuth)
- “Plan to throw one away; you will, anyhow.” (Brooks)
- like farming (Brooks, Hunt, Thomas)
- like oyster farming
- like hunting werewolves (Brooks)
- like construction (McConnell)
Some of these reflect a writer’s personal not the process.
Some may be more along the lines of wishful thinking. Is Gries really correct in terming programming a science, or does he just think that we should approach it that way? There is certainly science in the field of Computer Science (Despite the old joke that any field that has “science” explicitly in its title isn’t one: political science, domestic science, social science, … Anyone else I can offend while I’m at it?) Much of it is science only in the sense that Mathematics is a science – it still relies on a rigorous approach of hypothesizing followed by rigorous verification, even if that verification is not based on physical experiments. Still, programming may not be one of the more scientific components of Computer Science.
Since this is a course on “Software Engineering”, we might ask if programming is an engineering activity. The title certainly suggests that we would like it to be. Many “real engineers” would sneer at this suggestion, though, and there are very few universities in this country whose colleges of engineering include software engineering as a separate department from computer science, in the same way that, for example, chemical engineering and mechanical engineering are separate from the college of science departments of chemistry and physics.
There’s a touch of posturing and, perhaps, jealousy in our use of the term “software engineering”. Every few years, someone announces a new set of certification exams so that “software engineers” can be certified engineers just like “real” engineers, and columnists and bloggers begin to lament how few professionals in the field are “properly” certified.
On the other hand, if we take the broad view that engineering is the application of scientific knowledge to practical problems, there is a lot of software development that really is engineering. In CS361, for example, many of you will have learned how to select from among multiple candidate algorithms by mathematical predictions of their speed and memory use. That’s an engineering approach by almost anyone’s standard. It’s also true that many people grossly overestimate how “pure” many conventional engineering disciplines are. Much practical engineering involves little reasoning based on underlying science and more familiarity with the standards and best practices of that engineering community.
2 Software Construction
The collection of activities that actually produce the working software.
The diagram here shows several component activities that should be familiar to you from our earlier discussion of process models. The size of each cloud is intended to suggest the relative amount of time and effort spent in that activity. The position of the cloud, relative to the yellow oval that defines “software construction”, indicates whether that activity is central or peripheral to software construction, and whether it is entirely a software construction activity (e.g., coding and debugging), partially software construction (e.g., detailed design), or not part of software construction at all (e.g., problem definition).
-
Coding and debugging at the center, plus supporting activities
-
Excludes management, reqts. analysis, architectural design, UI design, acceptance testing, maintenance
- “the only activity that’s guaranteed to be done” (McConnell)
- the fun part!
Importance of Construction
-
central activity (30-80% of total project effort)
-
the “climax” of the development project:
- everything else builds up to or eases down from construction
- The product (source code) is often the only accurate and up-to-date description of the system.
- a favorite tenet of agile advocates
Questions
-
How would this picture change for incremental / agile projects?
-
What other changes have been made in last 10-15 years?
3 Key Construction Decisions
Some of the key decisions to be made before entering or during the early part of software construction:
3.1 Choice of Programming Language
What are the factors that would influence this?
- Expressiveness & Readability
-
“You save time when you don’t need to have a rewards ceremony every time a C statement does what it’s supposed to.”
-
- Familiarity
- Programmers with 3 or more yrs. experience are 30% more effective than similar programmers working in a new language (Boehm, COCOMO)
- Platform & Tool support
- Library support
3.2 Programming Conventions
- Naming conventions
- Documentation conventions
- Modularity conventions
- Style guides
3.3 Construction Practices
- Coding
- Up front versus incremental design (& reqts)
- Architectural decisions (e.g., error handling)
- Teamwork
- Team organization & roles
- Integration process
- Quality Assurance
- Testing standards and procedures
- Inspections, Pair programming
- Who has eyes on the code?
- Tools
- Version control
- Language & compiler choices
- language versions & features
- Frameworks
- Configuration control
- Integration tools
4 Looking Ahead
Through the rest of the semester we will look at
- Unit testing
- Build managers
- Version control
- Documentation tools
- Configuration managers
- System & regression test
- Code analysis tools
.