CS511 Final

(All problems are worth 2 points. Put the answers in order in your exam books. Put your name, ID and exam # on each book.)

1. Why is simple software code better than complex, tricky code? (Name at least 2 reasons.)

Simple code usually has fewer bugs, since there are fewer places it can go wrong.

Simple code usually has fewer bugs, since it is easier to see whether it is correct or not while it is being written.

Simple code often is faster than complex code, because there are fewer machine instructions.

With simple code, it is easier for the next person (often yourself) to find and fix bugs later.

Simple code is more likely to be a correct solution to the problem than complex code, although this is an article of faith rather than provably true.

2. Explain the key idea of the Mythical Man Month essay by Fred Brooks. (Focus on this essay, not his other essays such as Surgical Team, No Silver Bullet, and Information Hiding.)

People and time usually are not interchangeable. You usually cannot double the size of a programming team and cut the development time in half.  or

You can always create schedules with fewer people and more months. You cannot always create schedules with more people and fewer months.  or

Adding people to a late software project makes it later.

The reason for the above is the complexity of communication and coding interfaces in software development. New members of a team must come up to speed on the development and interact with many existing members. The work must be repartitioned to include the new members and this is complicated.

3. What is the difference between alpha and beta testing?

Alpha testing is done by a group that is internal to (or close to) the development team. Beta testing is done by regular users who are not connected with the development group.

4. What are the goals of feature set control? (There are two key points.)

Define a modest, manageable set of software features.

Hold the feature set fairly constant throughout the project.

(Most get both parts for full credit.)

5. Explain "code forking" within software development. When is it acceptable? When is it harmful?

Code forking is when some piece of source code is maintained in two (or more) parallel versions at the same time. Different changes are made, at the same time, to the different versions.

Code forking is OK when it is short-lived for a specific purpose. Such as testing a possible bug fix, or making a small change for one customer. The goal in these cases is to merge the forks fairly soon, so there is only one version of that source file going forward.

Code forking is harmful when it involves many differences for a long time (or forever). If the forks never merge and are significantly different, you are stick maintaining two (or more) versions forever. Unix is an example of this; it has forked many times without the different versions being merged back together.

6. What are four of the key ideas from Extreme Programming?

Embrace changes. Allow customers to think of new requirements and changes during development. Encourage them to do so, and change the program to meet their needs.

Customer is always available to give input. Ideally, someone from customer's organization stays with the development team all during development.

Lightweight development process. Be flexible and responsive. Don't burden the team with "heavy" processes such as CMM.

Creation of a set of "user stories" in place of a requirements document.

Pair programming.  All code created by two people sitting down together.

All programmers own all of the code. Anyone can fix or add to any code.

Frequent small releases. When working on one release, do not plan ahead to the next release. This allows customers to give feedback about each release, then adjust the next release based on their feedback.

No overtime. If project does not fit the time, change release plan to fit normal working schedule.

7. Explain the debugging process within open source software (for the kinds of projects presented in Cathedral and the Bazaar). Explain its advantages and drawbacks.

The open source project (executable and source code) is posted for everyone in the world to test and analyze. Anyone who wants to can test the program, then email bug reports and source code fixes to the project leader. The project leader reads all the bug reports and proposed fixes, decides which make sense, then enters the changes he choose to the master source set.

The advantages to this are: Many people are testing the software at once; you get lots of good bug reports. Many people are sending proposed fixes for the bugs, which may be exactly the right code needed.

The disadvantage is that one person is still reading and integrating all the bug reports and proposed fixes. Different fixes may be hard to reconcile with each other. The project leader must have the skill to make judgments about all the different fixes. There is parallel testing going on, but not parallel debugging.

8. Explain four important capabilities that Microsoft SourceSafe (or a similar source code control tool) provides.

Central library for all project files including, specs, code, documentation. Everyone knows where to find the latest master copy of each file.

Prevents two people from accidentally editing the same file at the same time.

For every file change, keeps track of who made the change, when they did it, and why (via the comments).

For every system version, keeps track of which edit version of every file makes up that system version.

Can retrieve all the files that make up any previous system version.

Can roll back to a previous version of any file; can undo the latest changes.

Can retrieve any previous version of any file at any time.

9. Explain the overall structure of the Software Capability Maturity Model (SW-CMM). Include goals, key process areas, commitment to perform, ability to perform, activities performed, maturity levels, measurement, and verification. You can use a picture or words or both.

Maturity Levels -- An overall rating for software development organizations. There are 5 levels.

Key Process Areas (KPA) -- Each maturity level has a small set of KPAs, which are the important components of that level.

Goals -- Each KPA has a small set of goals, which are the reasons why that KPA is important.

Common Features -- Each KPA has five common features (always the same), which show that the organization is really committed to these goals and how they are going to accomplish them. The five features are:

(Note to Nidhi: I can fax you a picture of this.)

10. What are two special qualities that are important in good game software, which are not typically so important in regular software? (I am talking about user-visible qualities, not internal code structures.)

Originality (should be different from other games)

Coherence (a consistent look and feel throughout)

 Interactivity (should respond to user input in interesting, novel ways)

 Fun Factor

11. Explain two problems with the Software Capability Maturity Model (SW-CMM).

Organizations look at CMM as a method or formula for improvement. But it is actually a set of goals, without specifying how to achieve the goals. To use CMM, you have to think, be flexible, be creative, and integrate the goals of CMM with the realities of your business. If you say, "we do CMM just like it is specified in the book", then you aren't doing CMM.

Organizations are using CMM as a stamp of approval, without really committing to process improvement. They want to find the easiest way to get certified as Level 2 (or whatever) without really changing their underlying methods. 

CMM focuses on management activities. It does not say much about how to write better code. This is unfortunate, since good code is the goal of software development.

CMM does not help at all for projects that are in a crisis right now. And this is often when companies look for help with their SW process. 

12. Within software development risk management, describe the kinds of risks you definitely should do something about. Describe the kinds of risks you probably should not do anything about.

Definitely address -- Risks that are likely to happen and would have bad results. For example, the main programmer has a known habit of quitting every job before the project is finished, but his knowledge is vital.

Probably not address -- Risks that are unlikely to happen and/or the result would not be very bad. Unlikely: meteor hitting the building. Result not bad: Employee gets sick for one day.

13. Suppose that a computer system runs correctly for 10 hours, then crashes and take 2 hours to fix, then runs correctly for 6 hours, then crashes and takes 2 hours to fix. What is the system's availability, as a percentage? Show how you calculated this.

total time = 10 + 2 + 6 + 2 = 20 hours
uptime = 10 + 6 = 16 hours
availability = uptime/total * 100 = 16/20 * 100 = 80%

14. What is the key difference between white box testing and black box testing?

White box testing uses knowledge of the source code to design tests. It attempts to exercise certain lines of code, or all lines of code.

Black box testing does not assume (or use) any information about the code. It just tests to see that certain inputs produce the correct outputs.

15. Explain stubs and drivers. During what kind of integration do we tend to use each?

Stub -- A small low-level routine that can be linked below a main routine. Stubs return a simple output or perform a simple action when called. We use a lot of stubs during top-down integration.

Driver -- A small main routine that can be linked above the routines being tested. Drivers create simple inputs to exercise the lower-level routines you are testing. We use a lot of drivers during bottom-up integration.

 

Copyright 2001, Charles H. Connell Jr.