A Concept: 159.2xx Development Methodologies

Ever thought "Massey should offer a paper in X"? This document describes the paper that I personally think would most improve the Computer Science offerings at Massey's Albany campus. As a lowly PhD student, I don't have the power to actually create a paper, but maybe one day, somewhere <wink>. This is a work in progress, but feel free to discuss it with me, anyway.

The assignments are just examples, of course, and they don't include the files necessary to actually do most of them. I'm sure you get the drift.

The textbooks need to be revised a bit, although they're only suggested reading anyway. I haven't completely read all of these, although I've heard good things about those that I haven't, or have at least read portions of them. Availability would need to be looked at, and there are probably some freely available books that would be good here (like Dive into Python).

In terms of language, the course would centre on C, because that is the language that the students should already be familiar with. However, other languages (here Java and Python, but other languages could easily be used, depending on the lecturer's preference) would also be looked at, demonstrating the similarities and differences of the overall concepts when applied in each language. This has the additional benefit of introducing students to a wider range of languages than just C/C++; this may also bridge between the majority of C/C++ papers and a few high level papers that concentrate more on Java.

Paper Outline

Paper Number & Title

159.2xx Development Methodologies

Points Value

12.5

Aim

This course aims to examine the software development process, including the tools and methodologies that are commonly used, to develop an understanding of each methodology, and when its use is appropriate.

Objectives

Still to be written

Subject Material

Topics covered are tools for collaborative work, documentation, unit testing, open-source vs closed-source development, using other people's code, 'Engineering' vs Agile methodologies, Extreme Programming, choosing the appropriate language, debugging tools and .NET.

Software packages used

• gcc C/C++, including gdb
• Check
• Java, including JUnit and jdb
• Python, including unittest, doctest , profiler , and pdb
• CVS, diff, patch (command line versions)
• pydoc, javadoc, ccdoc / doxygen

Calendar Prescription

Still to be written(65 words)

Learning Outcomes

On successful completion of this course the student should be able to:

1. Use standard revision control software.
2. Understand the difference between various common software licenses.
3. Use documentation, testing, and debugging techniques to improve their code.
4. Understand that there are a variety of methologies for software development, and know the key points of some.

Prerequisites

159.101 Programming Fundamentals.

It is recommended, but not required, that students have completed 139.177 Written Communication for Information Sciences.

Assessment

The course is assessed by four small assignments, two larger assignments, and an examination. This seems like a lot of work, but isn't: the small assignments are small, and if you can do them, you can almost certainly pass that part of the examination.

• Small assignments (14%)
  1. Using CVS - week 3 (2%)
  2. Documentation - week 4 (4%)
  3. Unit Testing - week 5 (4%)
  4. Debugging - week 6 (4%)
• Research - week 9 (15%)
• Development - week 12 (20%)
• Examination, 3 hours, covering the entire course (51%)
  You must pass the examination to pass the course.

Textbooks

There are no required or strongly recommended texts for this paper. The following texts are recommended:

• Python in a nutshell by Alex Martelli
• Essential CVS by Jennifer Vesperman
• Understanding Open Source Software Development by Joseph Feller, Brian Fitzgerald, Eric S. Raymond
• Agile and Iterative Development: A Manager's Guide by Craig Larman

Learning Methods

Still to be written

Student work load

It is estimated that the average work load (in hours) for this paper is as follows:

Lectures	39	3 hrs/week x 13 weeks
Tutorials	13	1 hr/week x 13 weeks
Assignments and Personal Study	104	8 hrs/week (approx) x 17 weeks
Examination Study	13
Total	169	ie 12 hrs/week (approx) during semester and 12 hrs/week (approx) during study breaks and exam period

Approximate Lecture Outline

3 hours of lectures per week, with an optional 1 hour tutorial.

Week	Topic	Contents
1	Introduction	Brief introduction to (or revision of) tools that will be used: Python, gcc, Java, and using the (cmd.exe / bash) command line.
2	Tools for collaborative work	Revision control (CVS, Subversion), using diff, and applying patches.
3	Documentation	Various coding conventions/style guides, emphasising documentation (Java, Python, C/C++), testing in documentation (doctest), automatic creation of documentation (pydoc, javadoc, ccdoc/ doxygen)
4	Unit Testing	An introduction, and examples in C (Check), Python ( unittest), and Java (JUnit).
5	Debugging	A practical look at using common debugging tools, including gdb, jdb , and pdb. A (brief) look at profiling (using the Python profiler as an example), emphasising that optimising is always left to last.
6	Open-source vs. Closed-source	A look at the legal and economic concerns of open-source vs. closed-source development, the history of open-source/closed-source development, and the typical differences in development styles (including looking at commerical open-source software, as compared to free open-source software).
7	Piggybacking	Using code by other people (both open-source and closed-source). Issues with reliability and licensing (including the basics of GPL, LGPL, BSD, MIT, Mozilla Public License, and the Academic Free License). Ideally including a guest lecture by someone like Paul Sumpter.
8	'Engineering' vs. Agile Methodologies	Feature Driven Development, Crystal family, Adaptive Software Development, Scrum/Sprints
9	Extreme Programming (XP)	An in-depth look at one popular agile ('lightweight') methodology. User stories, release planning, pair programming, XP unit testing.
10	Choosing a language	"There is no 'best' language, just ones more suited to particular tasks". Consideration of when to use interpreted languages (Python, Perl), compiled languages (C, C++, Java), declarative languages (Prolog), functional languages (Haskell).
11	.NET	(Brief) introduction to Microsoft's .NET, and comparison to Java/J2EE and Parrot.
12	Course Summary
13	Revision

Assignment One - Using CVS

This assignment is worth 2% of your total grade. It is due XX/XX/XXXX (week 3).

After completing this assignment, you should be familiar with using basic revision control tools, including using diff, patch, and CVS.

1. Using CVS, anonymously checkout the assignment_one_a module from [CVS server name].
2. Using CVS, check out the assignment_one_b module from [CVS server name]. Your username is your first name, and your password is your student ID.
3. Create a context diff of the files "one.txt" and "two.txt" in assignment_one_a.
4. Apply the patch "three.txt.patch" to the file "three.txt" in assignment_one_b.
5. Create a new directory, using your student id for the name, in assignment_one_b, and cvs add the modified "three.txt" file to it, committing your changes.
6. Tag your new directory with the date, in the format DD_MM_YYYY.
7. Use CVS to get the revision history for the file "four.txt" in assignment_one_b.
8. Release the assignment_one_b module from [CVS server name]

Hand in (electronically) a directory listing of assignment_one_a and assignment_one_b (before making any changes to them), a copy of the context diff of "one.txt" and "two.txt", a copy of the "three.txt" file after patching, and a copy of the revision history for "four.txt".

Assignment Two - Documentation

This assignment is worth 4% of your total grade. It is due XX/XX/XXXX (week 4).

After completing this assignment, you should be capable of documenting code in various formats, and writing doctest code.

1. Using CVS, anonymously checkout the assignment_two module from [CVS server name].
2. Document and clean up the function [function name] in the file "assignment_two.c" using the guidelines outlined in the revised Indian Hill C style guide.
3. Clean up the function [function name] in the file "assignment_two.cpp" using the guidelines outlined in the Wildfire C++ Programming Style.
4. Clean up the function [function name] in the file "assignment_two.java" to match the coding conventions recommended by Sun.
5. Write a doctest for the function [function name] in the file "assignment_two.py". The test should be thorough, checking for success, failure (including Exceptions), and covering all accepted usage.

Submit (electronically) your documented "assignment_two.c", "assignment_two.cpp", "assignment_two.java", and "assignment_two.py".

Assignment Three - Unit Testing

This assignment is worth 4% of your total grade. It is due XX/XX/XXXX (week 5).

After completing this assignment, you should be capable of writing simple unit tests.

1. Using CVS, anonymously checkout the assignment_three module from [CVS server name].
2. Write a unit test module for one of the files "assignment_three.c", "assignment_three.java" or "assignment_three.py".

Submit (electronically) your unit test module.

Assignment Four - Debugging

This assignment is worth 4% of your total grade. It is due XX/XX/XXXX (week 6).

1. Using CVS, anonymously checkout the assignment_four module from [CVS server name].
2. Select one of the files "assignment_four.c", "assignment_four.java" or "assignment_four.py".
3. Run this file (compiling as necessary), and use the appropriate debugger (gdb, jdb, or pdb) to find at least four errors in the code.

Submit (electronically) a description of each error you found, along with a brief explanation of how the error could be fixed.

Assignment Five - Research

This assignment is worth 15% of your total grade. It is due XX/XX/XXXX (week 9).

Write a 500 word report on one of the following research topics.

• CopyLeft: the influence of the GPL.
• Open-source language development: how [Python | Perl] is developed.
• Cost-effectiveness of open-source software in government organisations.
• A beginner's guide to open-source licenses - GPL, MIT, Mozilla Public License.
• A comparison of three GUI libraries - wxWidgits, Tcl/Tk, QT.

You will be marked on report presentation (20%), evidence of research (30%), ability to summarise research (20%) and demonstration that you understand the material, with an emphasis on the conclusions you draw (30%).

Submit (electronically) your report, ensuring that you have correctly referenced any sources you have used (you may use APA or IEEE style references).

Assignment Six - Development

This assignment is worth 20% of your total grade. It is due XX/XX/XXXX (week 12).

You are receiving this assignment in week one for a reason - you should start working on it as soon as possible, and gradually work on it as the semester progresses, applying new skills as they are gained.

1. Find an open-source project that interests you (for example, from SourceForge). This project may be coded in any programming language.
2. Evaluate the project, and find a feature or other improvement that could be added to it (many projects include feature request lists ('RFE's in SourceForge terms), roadmaps, and so on, that list these, although you may decide on one yourself).
   This improvement should be one that you expect to be able to implement in around 20 hours of coding (not including unit testing or documenting).
3. Let [the lecturer] know which project, and what improvement you have selected. This must be done by the end of week 4. If you have selected unwisely (for example if you are attempting a much too complex, or much too simple, improvement), you may be asked to revise your intentions.
4. Create a patch for the project that implements the improvement you have selected. Do not submit this as a patch to the project without prior approval from [the lecturer].
   Do not ask for help from the project developers. [The lecturer] will be monitoring the projects, ensuring that this is not the case.
   • The emphasis of the assignment is on following and analysing the development process itself, not the quality of your code; however, you should try and create as good a patch as possible. At the very least, it should work.
   • Document your code according to the coding conventions/style guide appropriate to the language it is coded in. [week 3]
   • As you are developing, create unit tests for your code [week 4].
5. Decide on an appropriate license for your code [week 7]. Note that you may need to use certain licenses to match the main project.
6. Consider how your patch could be further improved or extended (with a longer time period; for example, given a week of solid coding). Do not attempt to code these further improvements/extensions.

Submit (electronically) a copy of the patch you created (including the unit test modules), and a 500 word document outlining your experience of the development process, roughly composed as follows:

1. Introduction (as in any essay/report) ~ 50 words.
2. The project (the project chosen, and why) ~ 100 words.
3. The patch (the improvement chosen, and why) ~ 100 words.
4. The reasoning behind the choice of license ~ 100 words.
5. An explanation of future work on the patch (what, why, how) ~ 100 words.
6. Concluding remarks (any final comments about the development process). ~ 50 words.

You will be graded on the coding of the patch (25%), your unit tests (10%), following the appropriate documentation/coding style (15%), suitably formatting your report (10%), and the content of the report (40%).

Comments

Similar courses

Institution	Paper	Summary
AUT	406701: Software Engineering	The process of systems development, looking at project management, developer performance, and measuring this.
	407703: Software Project Management	Similar to the above, but more in-depth and for larger organisations.
The AUT papers concentrate more on management and evaluating performance than looking at the different methodologies and tools that are available for software development. There does not appear to be any component looking at documentation/testing/debugging, or comparing open-source and proprietory development.
Auckland	COMPSCI 280: Applications Programming	Developing applications with Visual Basic.NET, aimed at business students, rather than computer scientists.
	COMPSCI 732: Software Tools and Techniques	An advanced course examining research issues related to tools and techniques for software design and development; the exact content may differ from year to year.
The Auckland undergraduate paper is only really related in that it uses .NET; as a business-student-orientated paper, it is unlikely to cover different methodologies. The postgraduate paper sounds very similar to this paper, although, as it is postgraduate, much more detailed and in-depth.
Waikato	COMP153B,S Practical Programming	Visual programming, programming constructs, graphical user interfaces, data types and manipulation, problem solving techniques, documentation and testing.
Introduces documentation and testing, but doesn't go any further.
Massey (Turitea)	159.254: Software Engineering A	Rather like the first AUT paper, above.
	159.351: Software Engineering B	Rather like the second AUT paper, above.
Much the same as the AUT papers above, concentrating more on large organisations and management, rather than methodologies themselves.
Victoria	COMP 102: Introduction to Computer Program Design	The course focuses on programming and the design of programs, algorithms and data structures.
	COMP 201: System and Program Development	A course on software development and information management including object-oriented design, large-scale system construction, and an introduction to software engineering.
	COMP 301: Software Engineering Principles	The organisation, management, analysis, design and implementation of large-scale computer systems.
The first paper sounds more like 159.201, although "the design of programs" could include similar material, but since it is a 100-level paper, it is unlikely to go into much depth. The second paper sounds like many of the other papers listed here - concentrating on large-scale system construction and software engineering. The third paper also sounds like that, perhaps with some material that is covered in Information Systems at Massey.
Canterbury	COSC 224 - Introduction to Software Engineering	This course introduces current software engineering techniques and addresses the issues of developing large, complex software systems.
	Cosc314 - Software Engineering	A study of "programming in the large", specifically related to software engineering. Both the underlying theory and practical applications are covered. Small groups of students work together on a major software development project throughout the year. Concentrates on Java and UML.
Much the same as the AUT papers above, concentrating more on large organisations and management, rather than methodologies themselves.
Otago	INFO 221 Application Software Development	The general principles and methods of application software development. Development of problem-solving skills through the application of this knowledge in the construction of practical software applications.
	COSC 345 Software Engineering	This paper covers the development of large-scale, reliable, and maintainable software systems. Topics include software specification; software design; system design; formal specification; prototypes; system maintenance; code reading and browsing; software reuse; project management; human factors; documentation; standards for software and documentation; verification and validation; configuration management; and software evolution.
The first paper sounds like it may contain similar material to the debugging/testing part of this proposed course. The second paper sounds similar to the rest, but (as it is a 300-level paper), much more in depth.

Why this would be a good addition to Massey Albany's offerings

• It doesn't overlap with any other existing courses (so it can fit in without modification of other courses), but does link to others, particularly 159.201 (Declarative Programming), 159.331 (Algorithms and Languages), and 159.733 (Studies in the Practice of Computing).
• It also links (the section on documentation and the research report) with 139.177 (Written Communication for Information Sciences), and ideally students would have completed that course before this one, but does not duplicate any of the material from it (the documentation material taught in 139.177 is aimed at users, not other developers).
• There is a good mixture (particularly for 200-level) of practical and theory work. Students should be better programmers after this course, particularly in terms of documentation, testing and debugging, which are weak points for many students currently. At the same time, students are encouraged to think about the different ways that development can be done, and the theories behind the development methodologies. The first half of the course is predominately practical, while the second half is mostly theory-based.
• Students have to do more than write code to gain a good grade in the course (although coding is a major aspect of the assessment). This reinforces the idea to students that when they are employed utilising their computer science skills, they will not be just coding; at the least they will be documenting their own code, and they will probably have to write the occasional report, as well, or at least justify decisions that they make. For those that head into postgraduate study, the course gives opportunity for (basic) research, and introduces concepts that might be useful.
• The course strongly introduces the concept of open-source programming to students, which is not (deliberately) done in any other paper, although open-source tools (gcc, for example) are used, right from 159.101. The aim is not to push the idea that open-source is better, simply that it is an option.
• The course uses a variety of programming languages, not going into depth with any of them, which gives students a better understanding of the language options that are available. This should mesh well with 159.311 and 159.201, and means that students who do not prefer C (Java programmers, for example) have another language-agnostic paper option.
• The course fits well with the ACM Computing Curricula 2001. In particular, it addresses many of the Social and Professional Issues and Software Engineering topics that are recommended to form a part of a core Computer Science curriculum. Sub-topics addressed include SP6 (Intellectual Property), SP9 (Economic Issues in Computing), SE1 (Software Design), SE2 (Using APIs), SE3 (Software Tools and Environments), SE4 (Software Processes), SE5 (Software Requirements and Specifications), and SE6 (Software Valididation). It is similar to the example CS292: Software Development and Practice paper outlined in the ACM document.
  
  The course could also be modified to include various other ACM sub-topics, without fundamentally changing the design. For example, SP2 (Social Context of Computing), SP3 (Methods and Tools of Analysis), and SP4 (Professional and Ethical Responsibilities).
• The course would suit software engineering students well, who form a reasonable (and apparently increasing) percentage of the students taking computer science papers at Albany.

This work is licensed under a Creative Commons License
Created by Tony Meyer, 15th January 2004.