1. Define these three methods of integration testing: top down, bottom up, and
big bang. (1,3,5)
Top-down: First put together the
top-most (main) pieces of the software. Test these as a set. Will involve the
use of stubs. Then integrate the 2nd highest level of routines. Test
the (larger) resulting set. Continue to add more routines, highest first,
testing as you go.
Bottom-up: First put together the
lowest level pieces of the software. Test these as a set. Will involve the use
of drivers. Then integrate the 2nd lowest level of routines. Test
the (larger) resulting set. Continue to add more routines, lowest first,
testing as you go.
Big bang: Integrate all pieces of
the software at once. Then start testing. This is generally a bad idea.
2. What is abstraction in software engineering?
Abstraction is looking at a software system at various levels of granularity.
Or
Sometimes looking at just the top-most (main) parts of the system and ignoring the low level details. Sometimes looking at just the details of a routine and ignoring the big picture.
Or
Drilling down into a software design. First seeing the top-most (largest) features, then the parts of those features, then the parts of those sub-features, etc.
3. What is cohesion? (4) Do we want a lot or a little? (1)
The degree to which a module (or function or subroutine) is concerned with one thing (or concept or idea).
We want a lot.
(Note: Coupling and cohesion are not opposites. Each can exist, or not exist, independent of the other.)
4. What is coupling? (4) Do we want a lot or a little? (1)
The degree of dependence between modules (or functions to subroutines). Dependence means too many parameters, excessive use of global variables, reading private data in another routine, etc.
We want a little.
(Note: Coupling and cohesion are not opposites. Each can exist, or not exist, independent of the other.)
5. State two reasons why it is bad for a subroutine (or function) to modify an input parameter. (2,5)
The modified parameter could be passed back to the calling routine and cause problems later in the program.
It is confusing to the next programmer. It looks like that data is being used, when it really isn’t.
The routine might later start to actually use the input, which could introduce a bug that was not present before. This could be hard to track down, since it will not be obvious that the parameter was not being used before.
6. State two reasons why global variables usually are discouraged. (2,5)
It is hard to keep track of which routines are changing them or using them.
Changing a piece of global data can cause a bug in an unpredictable place, or in multiple places.
It is hard to tell how many inputs and outputs a routine actually has, because there are more than stated in the parameter list.
7. State two problems with using “hard coded” (or magic) numbers in a program. (2,5)
They are not self-documenting. You don’t know why they have the value that they do.
If you want to change one, you don’t know how many other places you have to make a similar change.
8. State two problems with complex, tricky programming style. (2,5)
Complex solutions usually aren’t as fast as simple solutions.
It is harder to find and fix bugs in complex code.
It is hard for the next programmer (including yourself) to understand the code later.
9. Why do we care about dependencies between various items in a software project configuration?
We want to keep the entire set of project documents in sync with each other.
Or
When we change one part of a project, we want to change all the other parts that depend on it.
Or
For example, if we change the functional specification, we want to find the design specifications that relate to this feature and change those designs also.
10. Give an example of a minor variant of a software configuration (or system).
A version of a system that supports B&W versus color monitors.
A change to the customer name (or logo) that appears on the opening screen.
A special fix for one bug, seen only be one customer.
11. Give three tips for good technical writing (1,3,5)
Decide who the audience is, and stick with it as you write.
Use a clear, easy-to-follow organization, and stick with it as you write.
Start with a general discussion, then get specific. This applies to the overall organization, within each chapter, and within each paragraph.
Use plain English. Use simple words and sentences.
12. What type of project risks should you definitely worry about and solve? What type should you probably not worry about? (I am looking for general descriptions, not details of specific risks.) (2,5)
Definitely worry about and solve – Risks that are likely to happen, and the consequence will be bad.
Not worry about – Risks that are unlikely to happen, and the consequence would not be bad.
13. Name two reasons why there is not more software re-use. (2,5)
Software developed
for one domain (subject area) is hard to re-use in other areas.
Software re-use is
not seen as a priority in large companies. Few incentives or rewards for
re-use.
Lack of standards,
so re-usable software pieces often don’t work together.
Little training
available.
Current models of
development do not encourage re-use.
14. Name two general design/coding practices that would lead to safer software in safety-critical systems. (2,5)
Simple design.
Better understanding of user-interface design and user psychology.
Build software to be safe, not just correct. Build in safety checks. Defensive programming.
Better documentation and training.
Investigate and follow up on accident reports.
15. Name three reasons that software development time estimates often are low. (1,3,5)
Scope creep. The list of features grows as the project goes along.
Basing estimates only on external deadlines.
New problem domains. New technologies. (Or new to this team.)
Optimism, assuming all will go well.
Trying to do too much. Taking on too complex a task.
Wanting to get the job. Wanting the business.