MNFIT-291: Software Project

In this course, students will work in groups of 3-4 individuals and carry out all phases of a software project, from the clarification of user requirements and formal specification to design, coding and testing stages, to the final demonstration and report. The results from each phase will be presented at mid-term and final class meetings and clearly documented in the final report.

Groups will work on projects that are either a) proposed and guided by IDI faculty members, or b) proposed by industrial clients and guided by IDI faculty members. Industrial projects are unacceptable if an IDI advisor cannot be found.

This course is only open to students who reside in or near Trondheim, or who plan to visit Trondheim MANY times during the semester. Students who have a "great idea" and want to work alone or with a friend and get credit for it should not look to mnfit-291 for an answer. A key aspect of this course is gaining practical experience in GROUP-ORIENTED software engineering for a customer/client, and this requires many real meetings involving group members advisors and clients.

1. Introductory Meeting: January 16, 2001 (9:15 - 12:00 in Auditorium L0 at NTNU's Lade campus)
2. Mid-term Progress Meeting and Intermediate Report Delivery: March 6, 2001 (9:15 - 12:00)
3. Final Presentations and Report Delivery: April 27, 2001 (12:15 - 15:00)

All students who were accepted into mnfit-291 and who wish to take the course MUST attend the Introductory Meeting. Students who were put on the waiting list for the course should also attend the Introductory Meeting, since accepted students who do not attend the meeting will be bumped from the course in favor of waiting-list students who do attend.

At this meeting, all project proposals will be presented. Students will then be given the opportunity to form groups of 3-4 members and register the group for one of the projects. Grouping and project registration will occur DURING the meeting, so students must act quickly.

To receive a passing grade in the course, a group must:

1. Give a 10 minute presentation that documents significant progress at the March 6 mid-term meeting.
2. Deliver the mid-term progress report (see below) by March 6
3. Give a 10-minute presentation that documents project completion and success at the April 27^th delivery meeting.
4. Deliver a complete and acceptable project report (see below) by April 27.

The mid-term meeting (March 6, 2001) is an important landmark in the course. At this time, all groups must show solid progress in the form of:

1. A Gantt diagram over the essential project activities
2. A concrete set of user requirements in both plain text format and in UML use-cases.
3. A formal specification of your system using UML's Class Diagrams and Collaborations. These should provide a complete and concise general overview that CLEARLY illustrate how EVERY MAJOR aspect of the formal requirements will be realized in the final system.

All of these items must be delivered as a hard.-copy mid-term report during the meeting. Your presentation should focus on the user requirements and the formal specification, and it should CLEARLY illustrate how the specification WILL FULFILL the requirements. 10 minutes is a relative heartbeat in the presentation world, so don't waste time with general discussion, complaints, excuses, etc. Get right to the point and stay there! Practice your presentation ahead of time and be sure that you can get across the key points in 10 minutes. Do not come to the meeting unprepared!! Any number of group members can present the work, but all group members should accompany the speaker(s) to the front of the lecture hall.

Group performance at the mid-term meeting will be formally rated as one of: satisfactory, unsatisfactory, or failure. A satisfactory rating indicates that all appears to be going well and that continued hard work should result in a passing grade. An unsatisfactory rating should serve as a warning that your group is a bit behind but should, with an increase in effort, properly complete the project. However, a failure rating means that group progress has been much too slow, such that completion of the project will involve too much ad-hoc work and corner-cutting, thus contradicting proper software engineering. A failure rating entails IMMEDIATE DISMISSAL of all members of the project group from the course.

Each group must deliver a copy of the final report to the course instructor by April 27, 2001. The report must include the following chapters:

1. A general description of the main project activities plus a Gantt chart covering the actual start and completion dates of these activities.
2. The complete user requirements described both in plain text AND in UML's use-case diagrams.
3. The formal functional specification involving UML's class diagrams and collaborations.
4. UML component diagrams covering a) the relationships between the main system components, and b) the organization of all source-code files.
5. The details of the testing phase, including the tests performed and the results.
6. A general discussion of the group’s experiences in working on the project.
7. A user manual that provides sufficient guidance for new users of the software.
8. A formal letter from the industrial client and/or IDI advisor that assesses BOTH a) the software engineering practices followed by the group, and b) the final system

These are the 8 required chapters for the course instructor. The advisor and client may require additional chapters and/or request the omission of some of the above chapters. In the former case, simply include the additional chapters in the instructor’s copy as well. In the latter case, two different reports must be produced: a short version for the advisor/client, and a longer version for the course instructor. Issues concerning report content should be clarified with the advisor and client at a very early stage in the project.

The course instructor makes the final decision as to which groups pass and which fail. Naturally, the advice of the client/advisor (chapter 8) is given careful consideration, so it is very important that your client/advisor takes the letter VERY seriously and provides more than just an "ok with me" assessment of your work.

Software development is normally an iterative cyclic process. All aspects will change constantly during the entire project, although, hopefully, the results of the earlier phases, i.e. requirements and specification, will change less and less as implementation proceeds. Hence, the requirements and specification that are delivered at the mid-term meeting will not necessarily be the same as those delivered in the final report. Also, the intermediate specification may not be as detailed as the final version.

The 2 delivery dates are NOT flexible. The only requests for deadline extension that are given consideration are those submitted by the project advisor or client which clearly indicate that the advisor/client is to blame for the delay. Failure to meet either deadline can result in a failing grade for the entire group. 

Student Groups

All students in a project group must be formally accepted into MNFIT291, and each group must consist of 3 or 4 students.

All groups should elect a leader, preferably a student with the best software-engineering background (via courses and/or job experience). Hopefully, the leader will simply serve as an administrative captain and contact person for a democratic team. (S)he will set up meetings, have a good overview of each member's activities, and insure that the group as a whole progresses at a good pace. (S)he should NOT be a dictator who makes all important decisions, but rather a person who keeps the group organized and on track. Most important decisions should be made by a consensus at the group meetings, but in cases of extreme disagreement, the group should trust the leader's instincts and allow her to have the final say.

Any group members who cause extreme problems for the rest of the group should be reported to the course advisor via an anonymous letter. One person should not ruin the possibilities for a passing grade for the other group members via laziness, disruptive behavior, etc. And group members who contribute too little should not receive 5 credits for their "work". In most groups, this will not be a problem as long as tasks are properly delegated among the group members.