Chapter 6 review. Are the following statements true or false? Explain why or why not.

a) Managing a large software system is like trying to hold 400 ping-pong balls in your arms.
True. The complexity can increase exponentially with the number of elements subject to change, particularly if we need to consider all the possible interactions between them.

b) Much of the complexity of programming-in-the-large is communication.
True.  In two senses: software components communicating with each other and human analysts, programmers and users communicating with each other.

c) A virtue of hardware components is that it’s relatively easy to get them to do new tricks.
False. That's the virtue of software: it's relatively easy to change. It's also the greatest challenge to management.

d) Modules, such as C++ classes, can help manage change and maintain order in software.
True. Modules prevent outsiders from changing implementation of modules.

e) Comments, such as those that determine the meaning of variables and functions, can help reduce the cost of software maintenance.
True. Programmers find it much easier to understand well-commented code, making it easier to debug or improve it.  Of course, comments are helpful if they are true (invariant) and clear (well written).

f) A “waterfall” model of the software life cycle encourages frequent re-analysis or re-design.
False. Implicit in this model is gravity, urging flow downward, stage by stage. Returning to earlier stages should require effort (like salmon swimming upstream), i.e., management approval.

g) A requirement specification explains how to implement a program.
False. Requirements analysis emphasizes what the system should do, not how. An analyst's main job is to understand the problem and its domain.

h) Definition of key terms is an important activity of the analysis stage.
True. Defining terms is an excellent way to understand the problem and its domain. These terms often become objects in a program solving the problem.

i) Design shifts from analysis (“what”) to implementing a program in C++ (“how”).
False. Design does shift to "how" issues, but not in any particular programming language. The output of design is a language-independent description of data (types and variables) and algorithm (in pseudocode) to solve the problem.

j) Pseudocode is fake C++ code—pretty useless!
False. Pseudocode-describing an algorithm without worrying about language-specific details-is very useful. Coding can then start with pseudocode (as comments), implementing code that should correspond to the pseudocode.

k) Some of the work of analysis and design can and should appear in a program’s code.
True. Putting the purpose, scope, definition of terms and pseudocode into the program as comments is a very good starting point. Just make sure the code does what the comments says it should!

l) A program will not run until you fix all the causes of all error and warning messages.
False. You must get rid of all error messages, but you could ignore warning messages. However, it's usually a good idea to make sure the warnings are not related to potential logic errors in your program.

m)Linker errors occur when a header file is missing or in the wrong directory.
False. Remember, header files contain source code; the linker combines object code. Linker errors may occur when object code, such as library files, are missing or in the wrong directory.

n) If a program runs without crashing unexpectedly, then it’s correct and you can hand it in—hooray!
False. There may still be logic errors in the program. You need to make sure the program is producing the right output, as predicted by the requirements. It's a good idea to develop test data and to make sure the program produces predicted results for the test data. When you hand in a program, hand in sample results with test data, for boundary as well as core cases.

o) When a compiler attempts error recovery, it may skip over some source code in a program.
True. For example, it may skip to the next semi-colon (;) in order to try parsing from the next statement. Thus you may find that several error messages pertain to one problem in your source code, so you ignore some of them; yet it may still be useful to look at error messages pertaining to lines further down in a program.

p) The time to plan how you will test a program is after you’ve written the code.
False. The time to develop test data is before you've written the code, while you are planning a solution (design).

q) It’s a good idea to test with boundary values, not just core values.
True. Boundary values test for cases that are more likely to cause problems. If you don't test for difficult cases, there's a good chance that bugs will surface later!

r) Debugging is another problem solving activity, only more fun.
True. Well, whether or not it's fun is a matter of opinion, but it is a problem-solving activity. Use decomposition by breaking the problem down into pieces (for example, by inserting output statements to trace parts of the program until you narrow in on the line that causes the problem). Use analogical reasoning by recalling similar problems and adapting their solutions-you'll get better at this with experience!

s) A breakpoint is where a program crashes, even more fun.
False. A breakpoint is where a program stops execution, at a point predetermined by the programmer, so that the programmer can examine the state of the program, such as the value of relevant variables, at this point. Must debuggers provide a breakpoint facility.

t) A structured walkthrough can help discover flaws in the design before implementation.
True. Just explaining to someone else what you propose to do may help a designer discover mistaken assumptions or faulty solutions. Structured walkthroughs are useful at every stage; for example, during debugging, explaining what you think the code is doing may help you to realize that the code isn't doing what you think it should. Aha!

u) A spiral model of software development allows for re-analysis and re-design.
True. Each loop in the spiral is another cycle of re-analysis and re-design. It's not that old results are thrown out though; rather, each iteration builds and improves on earlier ones.