CS 384 Midterm Review

The midterm examination in this class (CS 384) is an opportunity for you to think about what we've been doing, and what we are going to do. The questions do not emphasize memorization, but instead focus on integration and analysis. Three sample midterms are provided here with example questions for you from past semesters. Note that some of them may ask questions from a later point in the semester, over topics we haven't talked about yet. You can figure your midterm will emphasize topics where I've asked you to do work, or where I have presented materials on a subject in class. For example, anywhere on an old exam that SVN or CVS or Git were mentioned, you might expect a question on Mercurial. Another difference between these examples and your exam is that two of them are take-home exams, which generally might have more questions or expect longer answers than I will expect on Monday in a two-hour exam.

Midterm Exam Review

Dr. J's crude summary of lecture notes up to this point:

mapping UML models to code

if you are coding without consulting your software design, you are missing an important point. but how do you turn a diagram into code? Review for various UML diagram types, how to implement them.

pair programming

you were supposed to try it, seriously, and learn about it, whether you liked it or not. know the pros and cons.

test driven development

ditto as per "pair programming". This too is a core agile method.

software testing

testing for different kinds of errors, unit tests, integration tests, system tests, black box tests, white box tests, regression tests...

test plans and test cases

documenting how to test, documenting a test outcome. If you have done this and results are in SVN, then you probably learned how.

unit test automation tools

how to use them. how many tests are needed per unit.

coverage testing

statement coverage, (interesting subsets of) path coverage

inspections and walkthroughs

another kind of "software testing", sort of. Roles and objectives.

models of integration testing

big bang, bottom up, top down, and sandwich style

Highlights a Past Midterm Exam

We are using a "communist" model, we do not have decision makers

Real communists have no problem making decisions.

A management/design/integration team should be formed to keep track of decisions that were made

This is not a bad idea but is needed more in larger scale (> 8) teams.

The easiest way to keep everyone informed would be a required weekly progress report from each team, posted on a webpage, indicating what has been done, what problems they have, and what changes and decisions they've made.

Teams this semester do not seem to have this problem, although I worry about sprint planning meetings in which subteams spend the whole time chatting independently from the rest of their team, and not planning or coordinating with their teammates. For some teams the status/ reports mechanism is not public enough, not shared enough, or not persistent enough. A wiki is one option. Another would be to put it in the repository in the teams' docs/ dirs?

The design we did last semester was definitely not complete.

Still VERY true, heh heh.

"I did not even look at the design documents before I started my [part of the project], because they were not useful".

This is just sad.

"Many of the teams do not have unit tests in the repository."

Uh oh, still true.

object oriented paradigm doesn't lend itself to unit testing ?!

Patently absurd.

"The unit tests that are there are trivial"

Uh oh, probably still true.

Some general confusion about requirements vs. design vs. implementation

Um, yeah.

I have not taught you guys about coverage testing very well

Ouch. Still true. Can't ask much about things not covered in detail.