Software Engineering Capstone Team Project
CSC 478: Software Engineering Capstone
Spring 2018
Group Project Teams
Below is the initial list of teams I've set up, based on the choices made by the team captains. I tried to give each team captain at least one of the top two individuals they requested. At the moment, these teams are still tentative. The members of each team should immediately begin communications between each other, to discuss things like availability, skillsets, etc. If anyone has any strong objections about their team, please let me know as soon as possible. Early on, I can do a little rearranging, but once a team begins their discussions about specific projects, task assignments, etc., it becomes harder to change the teams. Concern that you don't have anyone on your team with extensive experience is not a sufficient reason to alter the teams. By this time, all of you should have enough experience to build a moderate-sized project, even if your only experience comes from the courses you have taken here at UIS. Keep in mind that the goal here is not to build an enormous project, but to build a project that is suited to your team's abilities by following a defined and documented process.
Also, and I'll repeat this again later since this has tended to cause problems in the past, the team captain is not the de facto project leader for your group. The team captain's primary role was to act as a hiring manager. Now that the teams have been set up, that role is no longer necessary. Each group must assign roles to each individual in the group. A group can certainly elect to have the team captain be the project leader, but can alternatively elect to have someone else fill this role.
I have set up groups on Blackboard with the following capabilities enabled for each group:
group discussion group email group file exchange group chat You are not required to use the Blackboard capabilities for your project. A lot of teams opt to set up their own versioning and file transfer systems, such as Subversion for versioning and Google docs for file transfers. You should all also have accounts with eDocs, the file sharing system in use at UIS. If you're not familiar with eDocs, basically you just go to http://edocs.uis.edu, and log in with your NetID and password. You can upload files and specify other individuals with whom to share those files. Instructions for using eDocs can be found at http://www.uis.edu/its/iss/edocs.html.
The first thing you should do is contact the other members of your team and get acquainted with each other. You may use the capabilities of Blackboard listed above, along with any other means you wish to use, to communicate with your team. As soon as possible, you need to work together as a team to accomplish three goals:
Decide on a team structure, and assign roles to yourselves (e.g., project leader, lead programmer, tester, technical writer, etc.). Although I did pick team captains for selecting the teams, the team captain is not the project leader by default. One of the goals of your first meeting should be to determine which role(s) each person should play. Feel free to allow these roles to evolve as your project progresses.
Complete the Scope Statement Assignment (located in the Group Project section). Remember, you only need to turn in a scope statement for your top-ranked project, not a complete design. Shoot for getting this done a week from now. Keep in mind that although the deadline for the scope statement is flexible, but the longer you wait the less time you will have to work on the project.
Decide on a team name other than the generic one I have given you. Email me your chosen team name, and I will update your group. Project Size and Restrictions
One of the challenges in this course is to choose a project that your team can complete in the time frame that is available, and is complex enough to be worthy of a group project. You will therefore need to strike a balance between including enough requirements to make the project worthwhile, and overburdening yourselves with a project that has spiraled out of control.
You have considerable latitude when it comes to choosing your project and its requirements. However, there must be a sufficient amount of functionality present in your final projects. It is difficult to pin down precisely what "significant" means in this context, but here are some examples of too little functionality:
A "Hello World" program. A client-server program that carries out simple functionality such as an online chat. A prorgam that serves only to display the data in a database. Some examples of acceptable projects include:
Most games, since the logic of the game must be implemented, and potentially AI players may be created. Applications that involve intermediate to advanced algorithms, such as schedulers; e.g., meeting schedulers, resource schedulers, etc. Simulations, since they involve modeling some fictional or real-world scenario, and require thorough understanding of that scenario. Software tools or utilities that perform some desired set of tasks. This could mean improving or modifying the functionality of an existing tool, or creating a completely new tool that no one has built before. Also, your team must write at least 50% of the code for your project from scratch. Although code reuse is commonly used and has many benefits, part of the purpose of the group project is to ensure your team is involved in all aspects of development. Writing and testing your own code is an essential part of the project's purpose.
I have noticed an increasing interest in building applications that must function over a network connection. I don't want to naysay all network-based projects, but I must caution you that I will have a very tight time window in which to grade all the projects. If you decide to build a network-based application it is entirely your responsibility to ensure the network connection will hold up during the time window I have for grading. If the network connection fails, and there isn't time for anyone from your team to fix it, there isn't much I can do except grade you on the other points in the rubric.
But don't try to tackle too large a project, either. The point is to have something that is complete (program and all documentation) by the end of the semester deadline. So don't be concerned about limited time—just try to pick a project that is feasible for a 12-14 week schedule.
I recommend making a list of all the requirements you would like to see implemented, but prioritizing them in such a way that you can still build a conhesive project even if you can't implement everything. The requirements that aren't implemented would hypothetically be added to the next version of the software.
Course Drops/Non-participation
As with all group projects, there is the very real risk that one or more members on a given team may either drop the course, or fail to fulfill their roles in the project. It is rare that a student drops this course after the second or third week, but it is a possibility. However, I have noticed that failure to fully participate tends to happen at a frequency of about one group per semester, for various reasons. The top three reasons I have observed, in order of frequency, are:
miscommunication or lack of communication other commitments that take priority over this course (e.g., paying job, often involving travel; certain family obligations) friction within the group The first reason can usually be handled pretty easily, as long as everyone communicates frequently (e.g., checking email daily). Also, make absolutely sure everyone has their responsibilities spelled out clearly and completely — don't make any assumptions about what anyone understands! The second reason is difficult to resolve, since it is unreasonable to ask a student to risk being fired from their job so they can spend extra time on classwork. Hopefully, those of you who are currently employed work for understanding employers, but I know that may not always be the case. Friction within the group usually happens because someone is disappointed that their project idea was not accepted, or because their input appears to be devalued. This can often be avoided if everyone keeps an open mind, and keeps the project in perspective. Easy to say, not always easy to do. I strongly suggest that each group democratically elect someone to be the project leader, and grant that person the authority to make final decisions — within reason, of course. In the event too much friction develops, the project leader should not be averse to relinquishing control, if necessary.
If your group encounters one of these problems, make a reasonable attempt to solve it amongst yourselves, but if you find you cannot resolve the problem contact me as soon as possible and I will do my best to help. If the situation cannot be resolved, you may need to do some reorganization, and even scale back your project if necessary. Keep in mind your grade for the project will not be proportionate to the size of the project, so if you do have to scale back your original plans, you won't be penalized. The only exception to that rule will be if you have to scale it back to the point where it won't have any functionality left. If that happens, let me know and we'll work something out. The main goal of this course is that you build the project as a team, the project has a reasonable degree of functionality, and you have thoroughly documented each phase of the development cycle you used. Above all, do not let a problem fester until it is too late to do something about it. You will be surprised how easily that can happen with only 16 weeks available.
A Word on Grading
Group projects are often stressful for students, since grades are dependent upon the performances of the individuals in a group. For those of you who may have concerns about grading, keep the following things in mind:
Project grades will be determined independently for each group, not by how well each group does relative to the other groups.
If disaster happens to strike your group, you will be given the opportunity to alter your project's scope as necessary to mitigate the impact of the disaster. So, for example, if your group loses a member, you can cut back on the size of your project without penalty.
If a member of your group does not fulfill his or her assigned obligations to the project, and I am aware of the situation in advance, I can assign grades to each individual separately, to minimize the effect of that single person on the final product. For example, suppose "John Doe" is responsible for testing your group's project, but only makes a minimal effort to test the project and document the results. If your group's Gantt chart and org chart clearly show testing as "John Doe's" responsibility, and the other members of your group have notified me in advance that there are concerns about "John Doe's" efforts, I can adjust the grade for your project such that "John Doe" bears the brunt of the penalty for lack of testing. Please note that in order for me to do this, I must receive sufficient notification in advance that there is a problem, and your project plan documentation must clearly show who on your team is responsible for which tasks. This is why it is important to keep your project plan documentation (e.g., Gantt chart and org chart) updated if you make any changes in group member responsibilities. If I am notified of a problem after it is too late to make any attempts to correct the problem, or if you don't provide me with your current org chart and Gantt chart, I will have no choice but to give everyone in your group the same project grade, which means if someone doesn't do what they are supposed to do, everyone in the group will suffer.
edited