CMSC 435: Software Engineering

• Time: Tuesday & Thursday 11:00-12:15
• Location: CSI 2120
• Texts:
  1. Perspectives on Software Engineering by Marvin Zelkowitz, ACM Computing Surveys, 1978
  2. A (Partial) Introduction to Software Engineering Practices and Methods by Laurie Williams (draft)
  3. Other papers and references as appropriate

  Name	Office	Office Hours	Email
  Marvin Zelkowitz	AVW 3175	Tues 1pm-2pm & Thurs 10am-11am	mvz@cs.umd.edu
  		In general whenever my door is open. It is best to email first to make sure I am around. Since I am no longer working full-time at the University, I am here Tuesdays and Thursdays, and at other unpredictable times as well.
  Manav Desai, TA	AVW 1112	Mon 3:30-4:30pm & Friday noon-1pm	manavd@umd.edu
  Cassandra Lewis, Project Mgmt	AVW 1112	Tues 4-5pm & Thurs 4-5pm	lewis.cassandra@gmail.com

• Assignment due April 9. Submit hard copy in class. You can use graphics software if you wish or draw figures neatly by hand.

  Turn in a Use case diagram and either a Transition diagram or Activity diagram for the following problem.

  Design a program that computes class averages for a class like CMSC 435. The raw data is:
  - Item 1 is exam 1, item 2 is exam 2, items 3-6 are phases 1-4 and item 7 is class evaluation. Items 1 and 2 are worth 25% each and 3-7 are worth 10% each. Each item has a value of between 0 and 100.
  - Read in the item number and its value until all items have been read in.
  - Compute the weighted average of the 8 items.

  Note that you are not to write the program, only design the use case diagram and one of the process diagrams.

1. Group project:
   • TSafe2c.zip - Zip file for base TSafe system to use. (2MB). Download and install on a UNIX system (e.g., glue).
   • TSafe User's Guide by Gregory Dennis, MIT, 2003
   • Local installation instructions
   • server.jar - Executable Java program to generate flight paths. Start this program before you start tsafe.
   • test1.txt - Test file of flight paths read by server.jar.
   • RunningTSAFE.doc - Running TSAFE on an XWindows PC
   • Source files for phases 2-3 of TSafe project: Class TSafe web page
   • Tentative schedule (A new group for each phase):
     February 24 - Design changes
     March 31 - Implement changes
     April 16 - Evaluate product
     May 4 - Document and package product
     TSafe project specifications - Version 4.0 of the project specifications.
   • Additional State Maps - Additional state maps for dynamic maps feature.
   • Additional tools - Tools to help generate test data for TSafe.
   • Group evaluation - Every member of group should print out, fill out, and submit this form at the end of each phase of the project.
   • Activity report- Every member of group should fill out, and submit this Excel spreadsheet at the end of each phase of the project.
2. Individual report: Topic due: April 1. Final report due April 30.
   Investigate some project that failed due to software. Explain the problem (Report guidelines). What happened? Why did it occur? What in the development process failed to permit the failure of the software? How could this have been avoided? If you had to pick liability, who was to blame? Has anything been done to avoid this in the future?

   If you are not sure of what project to discuss, see Dr. Zelkowitz first. If you pick something discussed in class (e.g., Ariane 5 failure, Therac 25), make sure you go well beyond what was discussed in class. Other possible choices: NASA Mars mission failures, IRS tax moderization system, Denver airport baggage handling.

3. On Thursday, April 16, the class will conduct a Perspective Based Reading laboratory for part of the time. Each class member is expected to read the respective documentation and participate in the activity. Your class grade on the activity is based upon your participation, not on how well you actually do in the lab. The goal is to introduce you to Fagan-like inspections.

   Each of you will read the requirements for an ATM machine, and then try to find as many defects as you can in the document. You are to study the ATM document from the perspective of one of three roles. All defects you find, regardless of how you find them, should be reported. You need to study the documents before class and then report on your findings and look for other defects at the inspection meeting on the 16th.

   Documents needed:
   - ATM requirements to be inspected
   - Design perspective
   - Test perspective
   - User perspective
   - Defect form to fill out before inspection
   - Inspection form to fill out at meeting. The forms should be self-explanatory. Found on this form means the role of the person(s) who found the defect.

   Each Phase 3 group will hold an inspection. The groups can organize themselves as to roles. One person will assume the role of tester, and read the test documents. One will have the role of designer and read the design documents, and one will have the role of user, and read the user documents. One will assume the role of moderator. The moderator will prepare for the inspection by reading the tester documents. During the inspection, the moderator will moderate the meeting and fill in the meeting inspection form. The only constraint on roles is that the group manager cannot be the moderator for this.

Class Resources

• Class description: required textbooks, course objectives, grading policies, etc.
• Syllabus: Defined by this web page.
• University computing information
• Java information:
  • Java Tutorials
  • Java Language Specification
  • Under the Hood articles
  • Java byte code basics
• Java sources:
  • Java version 6 update 11