Completing a project of this scale successfully requires that some explicit attention be paid to managing the process. Management is a responsibility of the entire team, though the team leader will naturally shoulder an extra administrative burden and will need to provide a steady influence.
Here are some ideas that you might consider as you work on your project. They have proven themselves useful to many teams in taming the complexity and pressure of large projects.
Most teams begin their project thinking that they don't need a team leader. They'll just do everything democratically. As good as that sounds, most teams who try it end up wishing they had selected a team leader.
A team leader can coordinate communication among the team and with the instructor. He or she can keep an eye on deadlines and deliverables, freeing other members of the team to focus on substantive tasks. And a good team leader can provide a gentle nudge or sterner reminder when team members need some help getting to work.
I've benefited from working on projects with good team leaders. I've also learned a lot from being the team leader on a project. (The project that taught me the most was probably when I worked on one of my most talented teams ever--a project on which we failed to meet deadline!)
In many ways, knowledge acquisition is the software development phase for which computer scientists tend to be the least prepared. For all the guidelines, techniques, and technological support that we define, knowledge acquisition ultimately comes down to learning a new task and domain. No amount of technology can change that. You have to study the new task and domain--carefully. You have to go in with and open mind, with questions--not with the idea that it's simply a matter of finding the right rules.
One of the best descriptions of how to do knowledge acquisition that I have ever seen is not in an AI book, or even a software engineering book. It was the introduction to The John McPhee Reader, by William Howarth. McPhee is a writer, a journalist, who contributes regularly to The New Yorker. He was in the vanguard of the New Journalism, in which writers with skills to create good fiction wrote non-fiction of depth and grace. In order to write great non-fiction in a new domain, one must understand it in a way similar to the way a programmer must understand a domain in order to build software in it. Howarth describes McPhee's approach to learning a new domain. I have pulled some excerpts from his description. Study them. They will help you do your job better.
And, by all means, feel free to read the whole introduction. The book is in the UNI library. Likewise, I recommend the book and much of McPhee's work, which is quite good!
Establish guidelines for the maintenance of team documents, from draft reports through design and pseudo-code modules to compiled code modules. Assign librarian tasks to one or more team members (not including the team leader) who will maintain archives and ensure that documents are added in accordance with team policy.
Consider scheduling two or three all-day work retreats. These can be schedules for Saturdays or Sundays when all team members can attend and devote their full attention. One retreat might be useful in drafting and assembling the Project Analysis/Design Document near the end of February. Another would be useful for writing the team's final documentation and report. Finally, a third would be useful for designing and preparing the team's final presentation.
Why go to the effort? Big tasks require complete attention. Short meetings require a lot of warm-up and cool-down time, making them less efficient. A full-day meeting helps all team members to focus on the project and to get maximize productivity out of team time.