Software Engineering



Course Projects


  1. Purpose and Method
  2. Team Work and Project Management
  3. Individual Contributions Breakdown
  4. Project Proposals
  5. Project Resources and Communications
  6. Report Format
  7. Project Demos
  8. Project Grading Policy

See here:   software project ideas and example past projects


Project deliverables
Iteration #1 Iteration #2
Proposal Report #1 Report #2 Demo #1 Report #3 Demo #2 eArchive

1.   Purpose and Method

The purpose of the course project is to provide the students with the knowledge of software engineering methodology and the skills to apply it. The particular project is not the goal in itself; rather, it serves as a vehicle to apply your knowledge and to develop the skills.

Projects also introduce students to teamwork, which is unavoidable for large-scale software development. Teamwork has positive and negative aspects, and a familiarizing yourself with both helps you get ready for your future workplace. There are many challenges to good teamwork: time coordination; building on each otherís strengths and compensating for weaknesses; reconciling different working styles, preferences, and levels of motivation; etc. A key challenge is to make possible group efforts that discern contributions of each individual. This is a challenge in the course, where each students needs to be assigned a grade, as well as in your future workplace where your raise and promotion will depend on your perceived contributions.

This project consists of two iterations of a software product. The first iteration is exploratory and represents the first attempt at developing the proposed software product. The deliverables for the first iteration are reports #1 and #2 and demo #1. After these, the instructor/TA will provide feedback and the students should reconsider and possibly revise the project goals before moving on to the second iteration. Keep in mind that it is perfectly acceptable to modify your objective in the middle of the semester, once you learn more about the project and have better understanding of what you can accomplish within the semester timeframe. (Of course, you cannot switch to a completely different project in the middle of the semester.) This is why we have two (2) iterations, so that in the second iteration you can perform the necessary adjustments, based on what you learned in the first iteration. The deliverables for the second iteration are report #3 and demo #2.

2.   Team Work and Project Management

Each team consists of 4 to 6 students. All students in a team work on the same project. Team work is required since team work is an integral part of large-scale software development. Requests for working alone or with a smaller team will be rejected—every team must have at least four (4) members.

When forming a team, keep in mind that the team size may affect your own grade. On one hand, teamwork is a critical component of this course and sometimes we (instructor/TA) prefer larger teams because we are unable to deal with the workload imposed by too many small teams. On the other hand, because grading is competitive, your own grade may be affected because you have to share the grade scores with more teammates. Here is a comment from past student surveys for this course:
♠   “There are groups with 6 members and there are some with 7 ... I do not want to be a victim of being a part of a larger group and hence ending up scoring less as compared to members of a 5 member group.
See here for more details on the grading policy.

You should form a team by the specified date and notify by email the TA and the instructor about the following:

  1. Team member names and email addresses
  2. Your project web site URL (one web site per team)
  3. Project proposal (see below)

All team members must take part in all project activities, although responsibilities may be divided so that different members take lead in different activities. But, none of the activities should be done exclusively by one student. While the volume of work of each team member on each project component may not be equal, their contribution to the overall project should equal out.

You will soon realize that teamwork is difficult and has negative aspects. Here are some suggestions (none of this is required!) about teamwork:

Team meetings should be structured to involve:

Tools to help organize the teamwork:

Saying that “nobody asked me to do this or that,” or, “I did everything that I was asked to do” is an unacceptable excuse. Each team member should be proactive and not wait passively to be assigned responsibilities. Do not ask others what should be done; rather, take initiative and suggest what should be done to make your project successful. Take every opportunity to redistribute and/or rotate the responsibilities, make your personal suggestions be heard! Many times defining the problem and determining what needs to be done is more difficult than actually doing it. Hence, problem defining and task assignment must be contributed to by all team members, rather than by the team leader alone.

The following free online e-book contains useful advice on how to work on student software engineering projects:
Tips to Succeed in Software Engineering Student Projects
Author: Damith C. Rajapakse, National University of Singapore
Publication Date: 27 June 2008.

What is the role of a team leader?

First, keep in mind that having a team leader is optional. You will soon realize that there are many things that need to be coordinated and having a single central point-of-contact may be helpful. You should elect the team leader only if you believe this would facilitate your group work. Alternatively, you can appoint individuals to coordinate meetings, deadlines, and track project progress, and rotate these roles among the team members.

The role of a team leader should not be misunderstood. The team leader is expected to provide organizational and logistical support (“project management”), that is, to organize team meetings and keep track about work progress. The team leader is not expected to set the objectives, partition the tasks, and devise solution strategies. These responsibilities must be shared equitably among all team members.

If you choose so, it is a good idea to select the team leader based on his or her leadership, organizational, and social skills, rather than their technical skills and knowledge. Past experience has shown that people with poor organizational/social skills turn out to be poor leaders and their teams end up being dysfunctional, regardless of their technical knowledge.

The leader is not accountable for “failing to lead” and cannot be blamed for the lack of communication skills or general lack of success of the team’s project. For example, the leader has no such responsibilities as “knowing what needs to be done,” assigning work loads (fairly or otherwise), or distributing the responsibilities. This must be agreed upon by consensus. Most importantly, each team member must be proactive, rather than waiting to be assigned the duties by the team leader or anybody else.
Remember, all team members are equally responsible for all aspects of the project.

There are neither benefits nor responsibilities for the team leader. The team leader will not receive any rewards (e.g., higher grade) for serving in this capacity. You will notice that a certain number of grade points for each deliverable is allocated for “project management.” However, these points will not be automatically allocated to the team leader. All teams are required to submit a breakdown of contributions. The grade points will be assigned based on this breakdown. See here for more details on the grading policy.

What if your team is not functioning well?

If you notice that your team does not function well or the team and this could negatively impact your project performance (and your final grade), you should make every effort to discuss this with other team members. If the “problematic” team members (including the team leader) refuse to cooperate, you should discuss your concerns with the instructor, the sooner the better.
Complaints about poor team functioning expressed at the end of semester will be ignored.

Additional information on project management

TechRepublic: Download this project status report template, created by project management guru Tom Mochal, to effectively communicate project status to stakeholders and keep everyone on the same page: Project status report template by Tom Mochal; July 27, 2005.

Project Management Methodologies, by Jason Charvat, published by Wiley, NJ, 2003. (A book review by R. Max Wideman)

Computerworld: Team-building with tofu and grapefruit—Paul Glen says that when putting together a team, skills are one thing, but it also helps to evaluate people’s personalities in terms of how ...

3.   Individual Contributions Breakdown

Many students find team work difficult due to different personal interests and working habits. Therefore, each student should keep track of his or her contributions to the project. The exact breakdown of individual contributions must be provided for every project deliverable, so that individual grades can be fairly assigned.

Here are some comments provided in past student surveys for this course:
♠   “It turns out that some groups have forced one student to do most of the work because they are not very knowledgeable with coding, or for other reasons. This is unfair, and students that want to work alone should be allowed to.

♠   “I didn’t like the group project experience cause kids that do not know anything and do not the work to be carried on the other kids that are actually doing the work. Having to show a Responsibility Matrix in the reports is unfortunately unfair. Half the time, I had to skew and scale the results of other teammates in order to make it look like they contributed equally; meanwhile I had to spend hours of my own time writing over 9/10ths of each report and over 80% of the code.

First, course survey is not the place to provide such information. This information should be given in your contributions breakdown. Second, unfortunately this is how real world works. In your future workplace, you cannot expect to be nice to all your co-workers and say that everyone has contributed equally, but then expect to receive a raise or promotion that you “really deserve.” You are not being genuine by outwardly promoting equality and secretly hoping for inequality (so that you get a better grade). The best approach is to be honest and report the contributions accurately. If you wish to help your colleagues, help them learn the course material better instead of doing their work for them.

The breakdown of individual contributions should be submitted:

Each student should provide an itemized list of his or her own contributions to the components of the particular deliverable, such as:
  . requirements specification (use cases and non-functional requirements),
  . software design (whole system or list the specific modules),
  . coding (whole system or list the specific modules),
  . debugging (whole system or list the specific modules),
  . report preparation (whole report or list the specific sections/diagrams),
  . Other: any other relevant contribution.
If several students contributed to a particular component, quantify, as a percentage, each student’s contribution to this component. Also provide a short description of your own contribution.

Team members who are not listed in the joint breakdown or do not email their contribution list will be considered as not contributed to the deliverable in question and will be assigned zero credit for this deliverable.

A potential problem has been observed in the past years. These projects are sufficiently complex that it is impossible for a single student to do everything. Good teamwork requires division of labor and building on each other’s strengths. Some team members may contribute more to design and documentation (report writing); others may focus on coding and testing the software (implementation for the demo). Let us say you have an ideal case where all team members are contributing to their best and everyone is happy with each other’s contributions. You may feel that just because some team members worked mostly on report writing, it is unfair to say in the contributions breakdown that others barely contributed. So you put “equal contribution” although you know this is not true. A better way may be to report the report contributions accurately and then give more weight to those team members who worked on the implementation and demo when reporting the demo contributions. This is why it is always best to be honest and list exactly who did what (instead of just saying “equal contribution”), item by item. If each team member genuinely contributed, their contribution will be appropriately rewarded.

Please keep in mind that you must inform us accurately of who did what if you expect us to assign the grades fairly.
There are seven project deliverables, so we need seven (7) contribution breakdowns from you.

4.   Project Proposals

Each team must submit a written proposal for their project. See here for more on Project Proposals.

Software class project ideas and example past projects are available here.

It does not really matter if the project was done before or it is being done by another team as long as you will not copy their designs and/or the code. Every problem can be solved in different ways. If you will come up with an original design and implement your own code, it is perfectly fine that you develop a product somebody else did earlier or is doing now.

NOTE: Unfortunately, the department is unable to provide resources for special project needs. Try to select the project and implementation technology that is generally available, since the logistics of project development and demonstration are entirely your responsibility.
See the next section about the resources.

5.   Project Resources and Communications

Online Tools for Software Development

Check useful free software available online.

A Microsoft site DreamSpark.com gives software to students for free. For example, Microsoft Project 2013, Microsoft Visio 2013, Microsoft Office 2007, Microsoft Lync 2013, and Microsoft Visual Studio 2012 are all completely free.

You may find useful this intro to Eclipse, an IDE for Java, C++, C, etc. programming  ◤  
CVS, open source version control   ◥   ANT, a Java build tool   ◣   JUnit, a unit testing environment   which is accessible in Eclipse   ◢   JCover, a test coverage tool for Java.
NOTE: You should also check the resources available in D-110, Engineering Building D-Wing.

Bitbucket  (Wikipedia article) allows you to host, manage, and share Git (Wikipedia article) and Mercurial (Wikipedia article) repositories in the cloud. Free, unlimited private repositories for up to 5 developers give teams the flexibility to grow and code without restrictions.

Example websites for free file hosting (you will need this for your electronic project archive):

Reading additional materials will likely improve the quality of your project. Additional online readings material is available here.

UML Modeling and Diagramming Tools

You may search the Web for other similar tools. Note that some tools lack support for some kinds of diagrams and others support only UML 1.4 notation (current standard is UML 2.3).
Microsoft Visio and open-source Dia are diagramming tools with a library of UML shapes that may also be used for drawing UML diagrams. (Rutgers students can download Visio at the University Software Portal.) Any tool that supports the UML symbology is acceptable.

Project Web Site and Web Log (Blog)

Each team should maintain a single web site per team, listing the team members and contact information. The purpose of this website is for the instructors to be able to track the project progress. All project material (progress reports, related web sites, etc.) should be posted on this web site. Important announcements should be posted as well.
Examples of free project or website hosting:

The team should also maintain their blog (an online journal—a freeform mix of news items, commentaries, and whatever else comes to mind), describing the project-related activities. You can get a free blog hosting on many sites on the Web. The blog should be linked from the project’s website.

Blog at WordPress.com

A good book about blogging is
Rebecca Blood, The Weblog Handbook: Practical Advice on Creating and Maintaining Your Blog, Perseus Publishing, 2002. Online at: http://www.rebeccablood.net/handbook/

2009 project: Educational Networking Tool for College Students

Departmental Resources

Due to the limited manpower, the ECE department’s system administrators cannot support many different software platforms and database management systems. They would be happy to set up for you a database account on a MySQL database server. Also, they can support JSP and PHP on the Apache Tomcat web server (Tomcat tutorial). In summary:

You may use other technologies if you like, but you are on your own. For example, you may wish to check PostgreSQL, claimed to be the world’s most advanced open source database. Check also PostgreSQL at Wikipedia, the free encyclopedia.

You may inquire about other technologies, we will try to help, but no promises can be made.

If your project requires creating a dynamic website (using JSP or PHP), ECE sys admins will create a group account for your team. Each team member will be able to add/change files on the account. Having a group account avoids the need to use your personal account, in which case you would have to give out your password to the entire group. For this, ECE sys admins will need everyone’s email. The group account passwords will be emailed out to the students in each group.

6.   Report Format

Three reports are required for the semester. A report is submitted by the whole team and will be graded as a whole, compared to other reports, and points will be split among the team members according to the declared contributions (details here).

A report must have a cover page containing:
  . the course title,
  . group number,
  . project title,
  . URL of the project website
  . submission date, and
  . all team-member names.
Negative points will be assigned to reports missing- or having an incomplete cover page.

The second page of each report must detail the breakdown of individual contributions to the project (use more pages if necessary)—see details here. Each student should provide an itemized list of his or her contributions to components of the report, such as:
  . requirements specification (use cases and non-functional requirements),
  . domain modeling (whole system or list the specific modules),
  . software design (whole system or list the specific modules),
  . report preparation (whole report or list the specific sections/diagrams),
  . Other: any other relevant contribution.
If several students contributed to a particular component, quantify, as a percentage, each student’s contribution this component.
If all members of the team feel that everyone contributed equally, you can just write “All team members contributed equally” instead of a detailed breakdown.
The reports missing- or having an incomplete contributions breakdown page will be returned for revision before grading.

The rest of the report must follow the detailed descriptions given here:

  1. Report #1
  2. Report #2
  3. Report #3

Reports should be prepared using a word processor and printed on a (preferably) laser printer. Handwritten reports or reports which contain handwritten material (e.g., figures, tables, etc.) will not be accepted. It is easier for us if you turn in your documents electronically in PDF format. Here is a PDF writer you can use from Windows. Macs automatically convert postscript to PDF by clicking on the file icon. There are UNIX utilities that convert postscript to PDF for Linux users; make sure you include all fonts in the created PDF.
Also see the list of PDF software.

Students are highly encouraged to use a software tool to prepare the UML diagrams for the reports. Any tool that supports creating UML diagrams is acceptable. Here are some options.

7.   Project Demos

The purpose of project demos is to complement the written project reports. See more on the demo format here.

Each team will give two demo presentations, each lasting about 15 min. The demos will take place in EIT Lab (D-110) unless stated otherwise. If you are using your own laptop/notebook to project the slides and run your software, please ensure that the video connector is compatible with the cables in the lab before the actual demo.

After the demo, each student should provide an itemized list of his or her contributions to components of the demo, such as:
  . software coding (based on, but not including, the designs specified in project reports) list the specific modules,
  . system integration,
  . testing and debugging (whole system or list the specific modules),
  . slide preparation and product brochure preparation,
  . demo presentation,
  . Other: any other relevant contribution.
If several students contributed to a particular component, quantify, as a percentage, each student’s contribution this component.
If all members of the team feel that everyone contributed equally, you can just write "All team members contributed equally" instead of a detailed breakdown.

It is essential that you email the specific contributions for each team member. Some people are more comfortable with public presentation and quicker to answer questions, so the instructor/TA may get impression that these students know the best and contributed the most. Hence, they will receive more grade points for the demo. Here is a comment from past student surveys for this course:
♠   “I was always under the impression that the demo was a group thing and that group members would be getting the same marks. I have a gut feeling that, just because I didn't "speak" at the demo, I was penalized despite doing work in the background.
If you did less-visible parts (coding, debugging, slide preparation, etc.), but you are not skilled with public presentations, then this is your chance to state your contributions. We cannot know what you did (and assign the grades fairly) unless you tell us!

8.   Project Grading Policy

Given that this is a design project, it is impossible to define precise grading criteria. The grades will inevitably depend on what student teams have to offer—so, grading is “market-based.” Those that offer the most-impressive product, receive the highest grade. Which means that, if you receive a grade you are not happy with, it is not necessarily that you did bad work; rather, it is that others did better. Of course, there may be several teams with an impressive product, so several teams may receive the maximum grade.

The grading policy for individual deliverables will be posted in the description of that deliverable. The specific requirements to be met will be listed. The reports will be graded based upon the technical content and clarity of exposition.
However, it is not enough to meet all the listed requirements to receive the maximum grade. For example, having a perfect report for a mediocre project will result in a low overall grade. Thus, the overall perception of the project (relative to others) is the key scaling factor for all other aspects of the grade.

Each student must be aware that a major part of his or her final grade depends on the team project. The failure to cooperate with other team members and invest equitable amount of effort can lead to undesirable outcomes. It is essential that you accurately disclose the individual contributions if you expect us to assign the grades fairly.

Grading the project-related deliverables works as follows. Say there are three teams, the first team has three students, the second team has two students, and the third team has four students. Then

  1. The project deliverable for each team is graded independently of each other. See, for example, how report #1 is graded. The maximum possible score that a team member can earn depends on his or her reported contribution breakdown. Te actual earned points depend on the judged quality of these contributions. Suppose that the team members earned points as follows:
    Team 1 reported “equal contributions”, but lost somewhere 10 points, so the remaining 90 points are split equally:
    Team 1: {member M1,1=30, member M1,2=30, member M1,3=30}
    Team 2: {member M2,1=21, member M2,2=50}
    Team 3: {member M3,1=21, member M3,2=12, member M3,3=35, member M3,4=26}

  2. Next, all team deliverables are compared as a whole relative to one another, and a holistic project grade is assigned.
    Let us say that Team 1 abd Team 3 appear to have done about the same size project, and Team 2 worked on a smaller project, so it receives 70 %. The teams project grades are estimated as   Team 1 = Team 3= 100 %, and Team 2 = 70 % (relative to the other two teams).
We can show the distribution of individual and project grades graphically as follws:
project grading
chart
It happened that teams with more members made bigger pies, but that does not necessarily translate to a better individual grade. To calculate each student’s individual grade, we need to determine the area of his or her pie slice. We do it as follows.

The above example scores are shown in again in the following table. Project grade column shows the relative overall quality of the deliverable, compared across all teams. The team member’s individual earned points are shown in the column Earned points. The next column shows the Adjusted points of all students, obtained by scaling their individual score with their project grade. The maximum score in this column is 35. Finally, the last column shows the Normalized points for all students.
This method compares each student’s contribution within the team and well as across different teams.

Team Project
grade
Member
ID
Earned
points
Adjusted
points
Normalized
points
T1 100% M1,1 30 30 (30/35 * 100) = 86
M1,2 30 30 (30/35 * 100) = 86
M1,3 30 30 (30/35 * 100) = 86
T2 70% M2,1 21 (21 * 0.7) = 14.7 (14.7/35 * 100) = 42
M2,2 50 (50 * 0.7) = 35 100
T3 100% M3,1 21 21 (19/35 * 100) = 60
M3,2 12 12 (12/35 * 100) = 34
M3,3 35 35 100
M3,4 26 26 (26/35 * 100) = 74

Late reports will be levied a late penalty of 10% per day, up to 3 days late. After that, no credit will be given, unless more than 40 % of team members (e.g., at least 3 out of 5) provide a written excuse from a physician. Since the deadlines are known well ahead, there will be no extensions for any of the deadlines. Please do not bother asking.

Contact the instructor immediately should you have any questions or concerns about the grading policy.


BACK TO:


Ivan Marsic
Wed Jan 4 19:52:45 EST 2012