Content of the team report:
1. Product-related information: WAArules.html
1. Current status of product:
§ What is the current status of your product?
It is ready to be released.
§ Are there parts of the product that have not been adequately tested?
Everything has been tested according to specification.
§ Are there product features that could not be implemented due to time or resource constraints?
We could have spent more time working on the AI part of the project. We did implement this section of the project, but we would have liked to have more time to spend on optimizing the agent.
2. Recommended work: This list can include topics such as known faults, enhancements of existing features, and suggestions for new features. If the features are described in your SRS or SDS, provide references to the relevant document and section. If the faults are documented in the VVR, provide that information. The goal is to transmit your ideas as clearly as possible.
Again, we with we had more time to perfect our AI strategy.
3. Advice to teams continuing this project: Include information that can help someone starting a new iteration with this project to get it started up again. Include information you feel is important but that is not documented elsewhere in the legacy.
The INI file contains information that defines the properties of the different animals.
2. Project team information: (Postmortem analysis)
1. Management objectives and priorities
§ In section 3.1 of the Project Plan, your team defined its management objectives and priorities. Revisit that description and rewrite it in terms of the objectives and priorities that have evolved through the semester.
To quote our project plan:
As mentioned before, we intend to work together as a team in a very democratic process. However, we realize the importance of placing someone in charge of each particular aspect of the project. The overall project leader will ultimately responsible for ensuring that everything gets done in a timely and efficient manner. However, he will also be able to delegate responsibility for specific aspects and modules to other team members. Our team members seem to work quite well together and we don't anticipate any major problems at the moment. Our top priority will be to successfully complete the project in the required time. We hope to learn good teamwork skills through the completion of this project.
This approach seemed to work quite well for us. We all had an equal say in how the project was to progress, but Kip had the responsibility to see that everything was completed. If there was every a deadlock in our democratic process, Kip had the privilege to choose which option we would go forth with. We met our top priority of successfully completing the project in the required amount of time.
2. Final team structure. In sections 2.2 and 2.4 of the Project Plan, you described your team's organizational structure and individual responsibilities. You have also revisited this issue in some of your activity reports. Describe the team structure at the end of the semester:
§ Who was responsible for which tasks?
Kip – Team Leader
Brian – Webmaster/User Interface
Jacob – Quality Assurance
Casey - Documentation
§ Did you rotate any of the roles?
No. The roles, however, were fairly informal. The roles were a way to assign oversight to ensure that things were completed on time.
§ Pretend you are just starting the project armed with your current experience. What would your team change about the team structure (if anything)?
Our team structure was ideal.
§ What advice do you have for teams wanting to use the same structure?
Keep it informal, but assign some oversight responsibility to ensure that things get done. The team structure, to us, seemed to be a fairly organic process that manifested itself naturally.
3. Schedule and planning:
§ Which aspects of your team's scheduling and planning procedures worked well?
We had an hour long meeting each week to discuss the past week's issues, set goals, and discuss design issues.
§ Which problems did your team have with scheduling and planning?
Class imposed deadlines were too artificial for us. Often the class deadlines didn't fit with the scope and timeline of our project.
§ What tools did your team use to assist you in planning and tracking the project?
We used informal communication and occasionally some written or drawn schematics. We were just a four-person team; there was no need to use a set of management tools that are geared towards larger projects.
§ How could your team have improved its scheduling and planning?
We could have spent some more time actually coding.
4. Support functions:
§ Discuss the effectiveness of your team's Quality Assurance and Configuration Management functions.
Again, this was an informal process, and it worked quite well for a team of four individuals.
§ What procedures did the team establish for defect tracking? How successful has the team been in faithfully using these procedures?
We took care of our own bugs, and verbally communicated with our teammates if they had defects in there code. The biggest part of QA for us was in pair programming.
§ What support function lessons did the team learn that would have helped if you had only known them earlier in the semester?
Let the support process grow organically. The most natural solutions are often the best solutions.
5. Work with the clients:
§ How did your team's relationship with the client worked out?
We didn't have any problems. For further questions about this please talk to Brandt.
§ What would you go back and change about this relationship to make it more effective?
Wouldn't change a thing. We valued the relatively hands off approach that was taken.
§ What could Dr. H have done to make the client-team contact more effective?
He could get more industry sponsors, and encourage teams to take industry projects.
6. Work with project mentors.
§ Discuss your team's experiences with the project mentor arrangement.
We met with Brandt (and Professor Henderson) once a week.
§ What advice does your team have for how this program can be made more useful from the point of view of the student teams?
I’d like to see more interaction, and participation, on industry projects.
§ Which aspects should remain unchanged?
The size of the teams seems to fit very well.
7. Other issues. Bring up any other issues from your team's experiences that should be recorded in this forum.
N/A
3. Feedback
from the mentors: Ask the mentors for their observations about the team's
accomplishments, the mentoring process, or other aspects of this semester's
mentoring interactions. One way to stimulate discussion is to provide the mentors
with a draft of the other sections of the final report and ask for their
comments and suggestions.
N/A
4. Three general pieces of advice to future S2S teams as they start out. I will add these points to the collection of advice from previous semesters. This will be your advice to future generations of software engineering students.
Have fun, and work on something that will challenge you.