Instructions

All questions are worth 1 point. The exam is worth 20 points. There are 17 questions. You start with 3 free points.

Put your name, student ID, and question sheet number on your blue books.

Return your question sheet.

Put all the answers in order in your exam book(s). If you want to go back to a question later, leave a blank page for it.

1. What is a driver? What is a stub?

A driver is a small main program, designed to call a subroutine or function that you want to test.

A stub is a small (almost empty) subroutine, or function, that allows you to test the main program before the subroutine is written.

2. Describe the linear-sequential model of software development.

Perform each phases of software development only once, and begin each phase only when the previous phase is complete.

Phases can include: system analysis, requirements analysis, (or definition) design (or architecture), coding, testing, maintenance (or revision).

3. Define requirements analysis.

Designing the features of a software system. The analysis tells us what the software will do, as seen by the user.

OK to say that the result of requirements analysis is a document called a functional specification.

4. Describe the spiral model of software development.

The software process is repeated again and again, improving (expanding) the software each time.

OK to mention that a new version may begin before the previous version is finished.

5. Define cohesion and coupling. For each, state whether we want a lot or a little.

Cohesion -- The degree to which each module (or function or subroutine) relates to only one thing. We want a lot.

Coupling -- The degree of inter-dependence between the operations of modules (or functions to subroutines). We want a little. Also OK to talk about too much code sharing, or too many parameters, or shared variables.

6. Name 3 reasons that software estimates are often too low.

Scope creep.

Basing estimates only on external deadlines.

New problem domains (or new to this team).

Optimism (or assuming all will go well).

Wanting to get the job.

7. What are boundary (or edge) conditions for testing? Why is it important to test these conditions?

Boundary conditions are the extremes of input – largest value, lowest value, fast input, no input, huge file, zero length file.

They are important because bugs often happen at boundary conditions.

8. What is regression testing?

Testing software to verify that something, which used to work, still works correctly. Often performed after some new code or feature has been added, to make sure the new code didn’t break something that used to work.

9. According to Ed Yourdon, what are 2 ways of effectively handling “death march projects”?

Triage: do only what really must be done, and defer other features. (OK, to state this as “review requirements doc” or “throw out unnecessary requirements”.)

Stop when the program is “good enough”.

Don’t make major changes to tools or processes.

10. Define software engineering.

Producing high-quality software in an efficient, predictable manner.

11. What are the 3 phases of every software project?

Definition, development, maintenance (or repair, or revision).

12. Define system analysis (or system engineering).

Designing or analyzing an overall system or process. The system or process may be more than just a computer system, and may or may not involve a computer in its result.

13. What is abstraction in software engineering?

Looking at a software system in different levels of detail.

Like zooming in and out of a picture or map. Sometimes looking at the big picture and ignoring details. Sometimes looking at details and ignoring the big picture.

14. Draw a picture of a software design (block diagram of modules) and show the following concepts: depth, width, fan-in, fan-out. Use labels and arrows to point to these items.

Answer on SEPA page 347.

15. What are the two kinds of comments that McConnell considers worthwhile? (I am not asking about physical placement of comments – like end-of-line or header.)

Summarize a section of code.

Explain why this code was written. (OK to say purpose or reason also.)

(Also OK to say “document surprises or unusual coding practices”.)

16. Explain “defect amplification”.

When one error multiplies into many errors, as software development progresses. OK to talk about errors growing worse or causing other errors as you go.

17. Describe 2 methods of designing for change. In other words, how can you design software systems so that they are easy to change?

· Identify areas that are likely to change.

· Develop plans for how to change these items.

· Use information hiding. (Or, reduce redundant code.)

· Define “families” of programs.

· Use object-oriented techniques. (Although this is not a cure-all.)