Assignment

• A project proposal: due on 10/3/07 for on-campus students and 10/9/07 for video students.
• A project summary due on 11/14/07 for on-campus students and 11/27/07 for video students; or an optional (formal) project presentation to be scheduled for the last 3-4 classes.
  Notice: This part is required for graduate students (those enrolled in CSE 7314) only, and optional for undergraduate students (those enrolled in CSE 5314).
• A final project report: due on 11/28/07 for on-campus students and 12/4/07 for video students.
  Notice: There is also slightly different requirements for graduate and undergraduate students, as described below.

Acceptable projects and project proposals

1. An application of some specific testing techniques/models to some programs/products you are developing/testing/maintaining/supporting. For example, you may choose to construct control flow and data flow models to test a module you are developing at your work. Another example is the development, validation, and usage of an operational profile for a large software systems you are working on.

   It's generally a good idea to consider multiple testing techniques and actually use a couple of them in your project to get a hands-on feeling of how different techniques and models work in practical applications.

   Pay special attention to the evaluation of your testing/analysis results. Be prepared to answer this type of questions:

   • How do you know if the testing technique works?
   • What's the basis for comparison (baseline)?
   • What about some other testing techniques that might be appropriate?
   You answer can be based on either the practical evidence (executing several types of testing cases and observing the results) or based on logical arguments (suitability of certain testing technique on certain types of products), or both.
   • Graduate students are expected to study relevant material from Part IV of our textbook to prepare them for the analyses above.
   • Undergraduate students can choose to perform only a high-level analysis to answer the above questions without going into details.

2. You may choose to focus on performing various other quality assurance activities and document the results, while performing limited/small-scale testing. Possibilities include comprehensive inspection, defect prevention and process improvement, formal verification, and fault tolerance. You may also collect inspection/testing/QA records for a product at your work, and construct quality models to analyze the results, to assess the effectiveness of your inspection/testing/QA techniques, or to identify high-defect modules for focused quality improvement actions.

   If you choose this second type of project, I still want you to perform at least some small scale/amount of testing because it is such an important part of our course. For the QA part, make sure you are focusing on quality that can be quantified and analyzed. (For example, a process definition/improvement initiative with only a logical argument for its superiority is not suitable for this class.)

   Again, the primary difference in the project requirements for undergraduate and graduate students is in the result analysis part, similar to that for testing-focused project discussed above.

Where to Find Something to Test or to Perform QA on?

• Well, I mentioned about your work, a product, or a sub-part of a product, that you are involved at your work. However, if you don't feel comfortable taking this as your class project or talking about it (without mentioning product name and raw data) in class, you need to find something else to work on.
  Notice: Your project report must contain testing related technical information, such as test models, test cases, and test results, although you don't have to give detailed product information. As a rule of thumb, if you feel uncomfortable with the material you you have to put into this report, find something else to work on.
• Many students used their past projects from work, from their former college/graduate school classes, from their hobby (e.g., game programming), or from their role as users of some specific packages/software/web-site/etc. Apply the same sensitivity rule as for your current project above.
• You can get it from someone else. Open source software and programs are a wonderful source for many student projects in the past as well.

Project proposals

• a one-paragraph abstract (at the beginning of the proposal),
• introduction: clearly identify the problem that you are going to address,
• brief background information (about 1/2 or 1 page),
• the solution strategy you intend to use (which testing technique? what kind of analyses? etc.),
• expected results,
• analysis of result to be performed,
• followup actions,
• a rough schedule,
• indicate whether you'll be making a project presentation, and, if possible, your preferred presentation date.

Please keep in mind that by the time you submit your project proposal, we have only covered less than half of the class material, although an overview of the whole course was given at the beginning of the semester. Therefore, you may make certain modifications to the things you propose, but the basic framework should be there in your proposal.

Once I have reviewed your proposal and provided my feedback (via e-mail to distance students), you need to address the issues I raised in your final project report. However, in most of the cases, you do NOT need to submit a revised proposal. In the rare case that your proposal is marked "U" for "unacceptable", you need to communicate with me via e-mails/meetings to make it acceptable, and you may be required to resubmit a revised proposal for this case.

Project summary or presentation? The choice is yours

You may choose to do a (full) project presentation. In that case, you don't need to submit the project summary. Each presentation could last anywhere between 10 and 30 minutes. You need to highlight the solution-strategy/results/analysis for us to get the basic picture, but not necessarily too much details about the background (one common mistake in the past is too much background information but not enough testing/QA-specific technical information) or the detailed test cases and activities performed.

As I stated earlier, this part is optional for undergraduate students.

Project report

For undergraduate students, you report should be similar, except the analysis part (see information in the "Proposal" section above). As a result, your report is expected to be around 10-12 pages. But, if you choose to, you can follow the instruction for graduate students as well.

A couple of common mistakes to avoid:

• It is supposed to be a "report", not a set of "presentation slides". So, limit your use of lists/bullets, and put most of the material/discussions in paragraphs.
• Your project report must contain testing related technical information, such as important test models, test cases, test results, and analysis of the results. In addition, you need to describe/discuss this information unless it is clearly self-explanatory.
• On the other hand, you shouldn't include all the graphs, models, test cases, etc. produced for the project in the report text itself. As I mentioned above, they can be included in the appendix, if you desire, together with other material, such as raw data, customer surveys, etc.

Sample project report:
Here is a paper based on the project report by a former student in the CSE 5314/7314 class.

Notice the different project requirements: We did not require multiple testing techniques then. So, only Musa-OP was constructed, validated, and used. You currently project needs to be more diverse, but may not need to have the same depth in each area as in this sample project.