Software Engineering Assignments 2006

Three Smaller Assignments

These assignments can be done by the groups of Componenten 2. They concern the product to be developed for Componenten 2.

• It is not important that all members of the group take SE.
• It is important that all members of the group who want to get SE credit for these assignments, are equally involved in the SE-related assignments, and that non-SE group members do not make significant contributions to the SE-related parts.

This is the schedule you are expected to honor for SE:

• Deadlines end at 18:00 on the date in the column labeled Due.
• Submit documents via PEACH; each document should be submitted only ONCE per group.
• Language: Dutch or English
• File format is either plain text (hard CR, no TABs, line length <= 80) or PDF (all non-standard fonts embedded).
• Document format:
  • Separate cover page with title, group number, date, version number, and for each author: name, id.nr., and relevant course codes (2IP30 and/or 2IF20).
  • Number all pages consecutively from 1.
  • If possible: number text lines, preferably shown in increments of 5.

Essay

The essay should be about an approved topic (see below for suggestions; your own suggestions are welcome) and it should be chosen in advance. When you want to take the essay option, each group needs to send me:

• Name(s) and student number(s)
• Topic
• Whether done in combination with Aspecten van Programmeertalen

• Deadline: 6 December 2006 (but this is negotiable, when properly motivated)
• Group size: at most 2 students per essay
• Language: Dutch or English
• Length: about 8 to 10 pages A4 (incl. references etc.); group size will be taken into account
• File format is either plain text (hard CR, no TABs, line length <= 80) or PDF (all non-standard fonts embedded).
• Layout: number the pages starting at 1
• Structure:
  • Cover Page with title, author's full name(s) and id. number(s), course name(s) and number(s), date
  • Introduction (single section, a few paragraphs), including
    • an overview of the essay's structure, and
    • the goal/thesis (a single short paragraph)
  • Core (exposition and development of ideas, etc.; preferably divided into a number of sections)
  • Conclusion (single section of a few paragraphs)
  • References (adhere to standard format for references; each reference must be referred to from the text)
  When applicable: evaluation, appendices.
• The essay must be your own work. It is an opportunity to show that you are able
  • to understand and apply the course material
  • to find related material in the literature
  • to compare such material (to each other, to the course material)
  • to evaluate such material
  • to form and express your own opinion about the material
• All "claims" must be supported, either by a convincing argument or explanation in the main text, or by suitably precise references (don't just refer to an entire book or website, but include more specific coordinates). That is, the reader must be able to verify the validity of claims, without the need to sift through loads of irrelevant material.
• Limited citations are permitted, provided that
  • the citation is clearly marked as such,
  • it is unchanged and correct,
  • it is sufficiently complete, to avoid distortion because of a reduced context,
  • it is relevant and to-the-point,
  • a precise reference to the original source is included.
• Limited diagrams and tables are permitted, provided their relevance is explained in the text.
• The relationship to software engineering must be self evident or clearly explained.
• The core of the essay must not be superficial, but should concern one (or more) software engineering topics in more depth.
• It is not necessary to cover the full scope of software engineering.
• If combined with an essay for Aspecten van Programmeertalen, then the page count is expected to reflect this (though not necessarily doubled), and the software engineering content must be substantial.

List of topics (note that these concern mostly some "idea"; you will have to find additional related material):

1. "Strategic Directions in Software Engineering and Programming Lan guages" by Carl Gunter, John Mitchell, and David Notkin in ACM Computing Surveys 28(4):727-737. [SE+AvP]
2. "Do we know enough to teach software engineering?" by N. Zvegintzov in IEEE Software, 20(5):112-111 [SE+AvP]
3. PHP evaluated from a software engineering perspective [SE+AvP]
4. Python evaluated from a software engineering perspective [SE+AvP]

   ---

5. "Software quality is still a work in progress, offshore and in the U.S." by Mark Willoughby in Computerworld (15-Sep-2003) [SE-only]
6. "New Findings Shake Up Open-Source Debate" by Mike Martin in NewsFactor Network (18-Sep-2003) [SE-only]
7. "Embedded Guru Advocates 'Bug-Free' Software" by Nicolas Mokhoff in EE Times (16-Sep-2003) [SE-only]
8. "Testing information systems during development will prevent problems in EurekAlert (16-Sep-2003) [SE-only]
9. "Buggy software taking toll" by Chris Cobbs in Orlando Sentinel (05-Oct-2003) [SE-only]
10. "Rethinking Software Testing" by David Rubinstein in Software Development Times No.87, p.29 (01-Oct-2003) [SE-only]
11. "The Future of Software Bugs" by Patrick Thibodeau in Computerworld 31(49):32 (27-Oct-2003) [SE-only]

    ---

12. "Open-Source Practices May Help Improve Software Engineering" in Newswise (12/03/03) [SE-only]
13. "Why Software Quality Stinks" by Jon Surmacz in CIO (12/01/03) Vol. 17, No. 5, P. 28 [SE-only]
14. "Unplugged: Charles Simonyi creates software intentionally" by Dan Farber in Tech Update (02/15/04) [SE-only, though combination with AvP can be discussed]
15. "A Copper Bullet for Software Quality Improvement" by Michael Blaha in IEEE Computer, 37(2):21-25 (Feb. 2004) [SE-only]
16. "Are You Ready for MDA?" by Scott W. Ambler in Software Development (02/20/04) (zie ook Examining the Model Driven Architecture (MDA)) [SE-only]
17. "Death by UML Fever" by Alex E. Bell in ACM Queue, 2(1):72-81 (March 2004) [SE-only]
18. "Why Software Still Stinks" by Scott Rosenberg in Salon.com (03/19/04) [SE-only]
19. "Tough Road to Quality Code" by Laurie Sullivan in InformationWeek (03/15/04) No. 980, P. 51 [SE-only]
20. "Why Software Quality Matters" by Deborah Gage et al. in Baseline (03/04) Vol. 1, No. 28, P. 32 [SE-only]
21. "Is Programming Dead?" by Jon Collins, on Silicon.com (23/04/04). [SE-only]
22. "Why Certifying IT Workers Won't Help" by Martin Brampton on ZDNet (27-April-2004) [SE-only]
23. "Federal Programmers Get Agile" by John Zyskowski in Federal Computer Week (04/26/04) Vol. 18, No. 12, P. 44 [SE-only]
24. "Finding Out What's Bugging Computers" by Kevin Coughlin in The Star-Ledger (06-Jun-2004) [SE-only]
25. "Location! Location! Location!" by Adam Kolawa in Better Software Vol. 6, No. 5, p. 32 [SE-only]
26. "Software Fuse Shorts Bugs" by Kimberly Patch in Technology Research News (07-Jul-2004) [SE-only]
27. "Father of Visual Basic Begs: Stop the Insanity!" by Lynn Greiner in ITBusiness.ca (09-Jul-2004) [SE-only]
28. "While Rome Burns?" by Rick Wayne et al. in Software Development 12(7):48 [SE-only]
29. "The New Rules" by Scott W. Ambler. in Software Development 12(9):83 [SE-only]
30. "Q&A: Agile Software Development Maximizes Project Rewards" by Stephen Swoyer. in Enterprise Systems (12-Oct-2004) [SE-only]
31. "The Quest for Secure Code" by Mary Kirwan. in Globe and Mail (12-Oct-2004) [SE-only]
32. "Better Software Through Source Code Analysis" by Jon Udell. in InfoWorld 26(44):47 (11/01/04) [SE-only]
33. "Software Factories Come Into Modern Times" by Stephen Swoyer. in Application Development Trends 11(12):24 (Dec. 2004) [SE-only]
34. "Postmodern Software Development" by Robert E. Filman. in Internet Computing 9(1):4 (5 Feb. 2005) [SE and AvP]
35. "The Myth of the Best Practices Silver Bullet" by Michael W. Evans, Connie Segura, Frank Doherty. in STSC CrossTalk (Sep.'05; p.14) [SE-only]
36. "Unified--and Agile" by Scot W. Ambler in Software Development (01/06) 14(1):49
37. "Make Your Development Process More Transparent" by Tracy Ragan in Software Test & Performance (01/06) 3(1):26
38. "Agile Programming Has Fallen Short, Conference Told" by Paul Krill in InfoWorld (13-Mar-2006)
39. "A Tiered Test Approach to Validating Software" by Aditya Dada in Software Test & Performance 3(3):33
40. "Take the Agile Path to True Balance" by Dean Leffingwell in Software Test & Performance 3(6):26
41. "Software Tools Detect Bugs by Inferring Programmer's Intentions" by James Kloeppel, University of Illinois at Urbana-Champaign, 6 July 2006
42. "The Future of Programming: Less Is More" by Daryl K. Taft, eWeek, 28 August 2006
43. "Avoiding the Most Common Software Development Goofs" by Ben Chelf, Dr. Dobb's Journal, 17 September 2006
44. "Software Development Methodology Today" by Bijay K. Jayaswal and Peter C. Patton, InformIT, 22 September 2006
45. "Scott Rosenberg: What Makes Software So Hard" by Edward Cone, CIO Insight, 5 January 2007
46. "The Trouble With Software Quality Control" by Colin Armitage, Dr. Dobb's Journal, 5 February 2007
47. To Be Extended