Experiences of Past Teams

Team A

CS 6370

Dr. Jones

December 10, 2002

Team A Post Mortem

What we learned:

The biggest thing we all learned from this project is the value of good design. We actually followed the software engineering process and did not do any source code design until after completing the Solution Space document. Hence all of our design was complete and ready to be fully implemented. As a result, the source code development was efficient as very little unknowns were left to discover and resolve.

What went badly:

Losing team members: We lost XXX in the first week of class (he may not have even known that the teams were changed). Then about half way through the course we lost YYY as well.

What worked well:

Having good team communication and cooperation provided a pleasant experience where everyone was willing to help out and use their personal expertise to provide an excellent product. Assigning two people to generate each document (usually a significant piece) insured that each one was done accurately and when the team decided. This alleviated any possible problems that might have arisen should one team member not have enough time to complete the necessary assignments. As a result, we have still completed our project at the final deadline and without degradation in quality.

What we would change:

The first thing that we would like to change is how the team assignments were changed so close to the first milestones deadline. This provided an initial precedent of being slightly behind schedule. Having meetings more often than once a week to discuss the documents face-to-face instead of making comments via email probably would have increased our efficiency and cooperation.

What we would keep:

Having a local group is probably the best thing that insured our projects timely completion. Several members of our group have professional experience in distributed software development and fully understand the extra cost involved (both because of communication costs and communication difficulties). The face-to-face interaction provided an opportunity to quickly make informed decisions as it allowed questions to be raised, answered and resolved efficiently.

Introduction -

It has been a good learning experience for all of us to work in a team environment and practice the software engineering techniques learnt in class. Most of the real world software projects built nowadays are huge and so are built by several people, who work on different pieces. Successful completion of a project, when working in a team requires -

1) Good communication and understanding between the team members.

2) Proper division of work between the members.

3) Different members having different specialization.

besides good technical abilities.

Our team had members from different countries, which required shedding our inhibitions and understanding others viewpoint. This taught us a lot about effective communication skills and respecting different views.

We briefly discuss the approach we took which helped us in our project work, things that did not work well and what we will keep in mind while working on future projects.

What Worked-

1) In our first meeting, we discussed what each one was good at and accordingly assigned tasks to the members, which everyone followed.

2) We collected everyone’s schedule to know what times were best for everyone to meet. We decided to meet once or twice in a week, which we did regularly.

3) At the end of every meeting we set an agenda for next meeting and came prepared to discuss about those things, so we saved our time by being well prepared and knowing in advance where we were heading.

4) We used WinCVS as a repository for storing all the documents and code. This helped, as everyone could access, make changes and commit things and have the most recent version of things.

5) We divided our team into two subteams, each one headed by a main programmer who had good knowledge of the tools and languages used, and having assistant programmers. Within the subteam also we divided the work

6) Each one of us sincerely performed the duties, so it became very easy to work. It never happened that a single person was overburdened with tasks.

7) We had a thorough design, which helped in faster coding.

8) We chose to do a software project that was reasonable and not too challenging.

What did not work-

1) We slid behind schedule for submission of the problem space and solution space model, as some of the team members had gone out of Logan.

2) We got less time to code and test the software because of the schedule slip.

Lessons Learned -

1) It is important to follow the schedule and the proper distribution of time for different activities.

2) Think about the delays, which might occur ahead of time and have measures for ways to recover from them, for example, use more time and effort but complete a particular phase on time.

1. Introduction

This document will serve to analyze the development process and team coordination of our software project

“Defect Tracker.” There will be sections on:

What we learned

What went well

What went badly

What was most useful

What you could change

Paragraphs are representative of individual comments. There may or may not be a flow of ideas or

conceptual integrity throughout each section.

2. What we learned . . .

We learned several things. First of all team communication is critical to success. Our team communicated

very well which was an important factor to our success. We learned that it is not easy to coordinate efforts

by telecommuting. Some of our team members were not close enough to be able to attend a face-to-face

meeting and this (although overcome) was a challenge.

You need at least one person on a team who has a really good understanding of the overall project and

really takes ownership to see it through. We had such a person and we never would have finished without

him.

3. What went well . . .

Our team communicated very well. We all shared phone numbers and communicated as often as needed.

We had a few face-to-face meetings. We also used a “Yahoo Group” as a communication medium. The

Yahoo page was extremely helpful and accomplished several things for us.

It was a central communication base where all inter-group messages were stored for later review and could

be accessed by all in the group. It was a central file storage repository. This made is very easy to store files

and coordinate the development of documents where all could review them.

It provided a central secure data storage location for team members contact information so we could more

easily keep in touch with each other. Scheduling capabilities were also there although we did not use it that

much.

Our decisions to use open-source software was also beneficial and allowed all to have access to the

necessary development tools for the project.

Our team divided responsibilities evenly and fair. We had an initial face-to-face meeting where we defined

roles, responsibilities and divided them up to team members. No one had an overwhelming burden and all

were fairly busy fulfilling their responsibilities. This was also critical in getting a good head start on the

project and allowing us to complete in a timely manner.

The separation of tasks to individuals was executed effectively and efficiently upfront in time for

ownership.

Confidential .CS6370 Team C, 2002 Page 4

Defect Tracker Version: 1.2

Project Post Mortem Analysis Date: 12/10/02

Each person was responsible for roles within the project and they were assigned early enough to have an

understanding of the deliverables and effort required by each person.

The coding of individual object interfaces was effective. The overall design by one individual maintained

conceptual integrity as one person made all design decisions. Coding decisions were clearly defined and

did not overlap.

The face-to-face meetings for me were invaluable. Having a team member with a ‘vision’ of what the final

product should look like really helped drive the process

4. What went badly . . .

There is very little that our team did which caused anything to go very badly. Probably the worst thing is

that although our project was completed on time, we were consistently behind schedule. A late push and

lots of hours from several team members helped complete the project. This would not have been necessary

if the project had been better managed.

Communications was at times lacking. Emails were sometimes not responded to (the premise being that

the receiver did not value the message).

It would have been nice to see a copy of the Sommerville reference. It would have made things a little

clearer as to what artifacts we should have been producing and why.

5. What was most useful . . .

Yahoo group was the most useful thing about our project. It was also very beneficial that all of our team

members were professional and mature in the fulfillment of their responsibilities.

6. What you could change . . .

The very first thing we would change is initial team decisions. It seemed to be quite a while before it was

decided who was to be on our team and even then there was still some shuffling going on. By then we

were already way behind schedule. This is a problem Dr. Jones would have to address.

Second, it would be beneficial to have team members located in generally the same geographic regions.

Having team members in “far away” places complicated the development process. This should be

corrected unless part of the course is to learn to develop in this type of environment. In that case, we

succeeded and there are no improvements to be made.

There should have been weekly status updates so that all parties involved could be kept informed and

pressure applied if necessary when/if falling behind.

Some review sessions would have helped get everybody involved and allowed for more timely submissions

of deliverables. We could have used Webex meetings with conference calls to discuss deliverables, see the

documents, and respond real time instead of posting to the group page and assuming everyone had

reviewed the document by the time the poster had suggested.

It is communication that is the most important aspect for successful projects. This communication can only

occur through email, phone, or collaborative technology. An over abundance and even what might be

considered overkill is usually required.

We would like to stress how difficult it was working without “face to face” meetings. We really only had 1

or 2, and never one where everyone was present. Most other problems we had with coordination or

planning would have been more easily resolved with these meetings.

All pertinent information from the Sommerville text should be put online or each team should be required

to buy one if it’s so good, or we should not use it.

We would emphasize the process more than the final product. It might not hurt to sacrifice the size of the

final product to help understand the artifacts that are to be produced. Having turned a lot of ours in late we

don’t think we got the feedback necessary to understand what we did well and what we could improve on

documentation wise.

It would have been nice to do more prototyping earlier on, it would have helped in the overall

understanding of the product and we would have avoided the late rush where one person had to make most

of the changes.

It would have been nice to use a code management tool like CVS.

CS6370
Team K
Project Evaluation
Due: 12/11/2002

What did you learn?

We learned how to use different software development tools. These tools included the Microsoft Visual C# development environment, the Microsoft Visual Studios Setup and Deployment system, and the PaceStar Software Edge Diagrammer.

We learned that a software project is more than just code and an executable. To complete a software product, it includes a number of deliverables. We learned what these are.

We learned it is very important for each individual on the team to have a very clear vested interest in the success of the project. The needs of the individual team members need to match the requirements of the project.

We learned that teamwork is a must. When a team member is assigned to do a task and they are not able too, other members of the team must step in and pick up the slack.

What worked well?

One of the things that worked well for us is that we had a project disk that had a folder for each member of the team. It also had a folder for each deliverable item. As one member was working on his assigned portion, he would put things he wanted to make available to others in his own folder. When it was near completion, it would be moved to the deliverable folder. This helped each person to know where the others were. This also helped make completed items available to everyone on the team.

Another advantage we had was ad hoc communication. When changes were made, we were able to quickly make everyone aware of them and re-focus our efforts.

We also had a weekly meeting where we would meet and update everyone on where we were and make assignments to each person.

It was helpful for us that the instructor was patient and allowed us leeway on deadlines. Because we were able to take a bit longer on some of the items, it allowed us to have the time to ensure they were higher quality.

Another thing that worked well for us was to have access to the ideas and thoughts of the USU Facilitator at our site. When we had questions, we could go to him.

What worked badly?

One of the difficulties we had was knowing exactly what we needed to do to complete some of the deliverables. It would have been helpful to see samples of the different deliverables before we had to turn them in.

At the start of the project we decided to use some project tracking forms. These were used for the first few weeks and then we just forgot about them and did not use them. It would be helpful now to know how many hours each person really spent on the project.

Some members were spread very thin and had other obligations not pertaining to the project and they were unable to contribute as much time as all of us would have liked. Two team members put in significant overtime to make up for these deficiencies. Although this was difficult for them, it made it possible to complete the project by the final deadline.

One team member moved in the middle of the project and was not able to help for the remaining portion. We did have two new team members, one helped only with testing and the other helped only with generating the html reports.

What was most useful?

Of all the things that helped our team, the things that were the most useful were as follows.

(1) The ability to communicate and have regular meetings to keep the project on track was very useful.

(2) Another thing that was very useful was the review process that we used. As items were completed, they were reviewed by other team members for correctness. Before items were submitted, they were reviewed by at least two people.

(3) The availability of tools was very important. It was very important to have a GUI development environment. It was also very important to have a good UML modeling tool. Without these, it would have taken much more time (that we did not have) to complete the deliverables.

(4) The support we had from the USU Facilitator was very helpful. In the time critical parts of the project, he was able to help re-direct the efforts of some of our team members so they could put in the time we needed them to on our project.

How would you change next time?

One of the things we would change is to try to help each team member have more realistic expectations of the time they can spend on the project. We would add better accountability mechanisms so that team members would understand what is expected of them and when.

We would focus on better time balancing so team members are not spread too thin.

We would keep more accurate records of time and contribution to the project.

We would try to better match up the requirements of the project to the desires and needs of the team members so that all members would have a very clear vested interest in the success of the project and how it will help them personally for it to succeed.

Scott B.

Project Evaluation

Part of Team A

Learned:

This project has been quite the experience. I have learned many things regarding the development of software. One of the most important things that I have learned is that when you are working on a big project it is important to have a team that has the skills required for the project you are working on. Initially none of us knew any GUI stuff at all.

Worked well:

One thing that our group did well was to start the planning early. This way the team can decide on design decisions and start coding as soon as possible. I think that this is something that our group did really well. We were able to get most of the code done really early so that we had more time to debug, refine functionality and add functionality.

Worked badly:

Our FTP site really gave us problems. If I were in industry and had more time I probably would have pushed to change the FTP service.

Most useful:

The most useful thing for our group was the meetings that we had twice a week before class. These were short and simple but they accomplished a lot and we were able to keep up to date on assignment dates and progress of the code.

I would change:

If I were to do this again I would find away to break the code up more. Since I was the main guy who new Visual Basic I ended up doing most of the GUI code. There were some people in the group that did help me which was good but it would have been better to have even more learn it so that they could test and fix bugs.

Overall, fun project.

Phil G.

Project evaluation

Learned:

I learned how much work goes into managing a project for software development. I was amazed at how many documents we needed to create and maintain as well as how many man-hours were required to create the program.

Worked well:

I thought it worked great how we spent the first week researching the different languages on how they would be able to facilitate the assignment. That way when we started coding, we knew that it would be able to meet the requirements. I also think it was very good that we started coding so soon. This gave us plenty of time in the end to fix bugs as well as add extra functionality and proper documentation.

Worked badly:

Our FTP site didn’t work well and made sharing of code difficult. Getting all members of the group to contribute was also a challenge at times.

Most useful:

I think meeting twice a week at the same time and place was very valuable. We were able to stay on task as well as up-to-date. It also helped in group unity.

I would change:

I would want to learn more of the visual basic. I spent the majority of my time doing documentation or trying to make sure everyone else was getting things done by deadlines and setting new ones. I learned a little code, but I would have liked to have done more.

Stephen A.

Project evaluation

Software engineering is more difficult than I thought. When we first started I was completely focused on how we would overcome the technical aspects of our project. No one in our group had experience with this type of project, especially interfacing a GUI. Little did I know that technical difficulties were but a small portion of our struggles. Communication was a major difficulty. We had no formal channels of communication. Typically I would communicate to team members through emails, casual group meetings or brief conversions after class. There was never a time that our entire group met during the entire duration of the project.

Putting that aside, we did some things extremely well. We had good chemistry. We had a casual relationship and we openly communicated. Ideas were not stifled.

If I were to redo this project I would pay more attention to our deliverables. These are a very significant part of our grade, we focused on creating a “slick” piece of software, however, good documentation really helps the process, and the grade.

James Z.

Project Evaluation

During this project I learned more about team work and deadlines than I

learned about coding. It was most beneficial in that sense because it

taught me how to appreciate what it takes to make a team and how a team

functions. Overall I learned that a good team effort will produce a better

product but that it isn't easy to produce a good team effort.

I think that our weekly, same time, same place meeting worked best for us.

I think that the other team members were the most useful things I had at my

digression this semester, they were very helpful and explained things to me

when I didn't understand them.

If there were a next time, I would have liked to have had some examples for

what was expected for a lot of the documentation, since the assignments were

somewhat vague and it was hard to do it right.

CS2370

Team B

Project Evaluation

We learned a great deal from our software engineering project about working as a team and developing software. We gained practice researching different software tools and languages, expressing opinions and making compromises as a team, and managing a schedule to complete a large project on time.

One of the best decisions we made as a team was to meet weekly so we had regular times to check our progress and plan what to do next. Also having a team ftp site as a common place to exchange documents really helped communication, and prevented us from having to carry around numerous disks.

Everyone on our team willingly participated in designing and programming. We assigned everyone part of the programming responsibility and made it clear who was responsible for what part. For the most part, everyone succeeded in the jobs assigned to them, although there were a couple of instances when jobs were not completed quite as quickly or as defect-free as the manager would have liked. In those instances the manager should have done a better job of assigning more people to those tasks.

Everyone also took turns in helping to prepare the documents. Having one specific person in charge of each document was a good idea because it did not put the entire documentation tasks on one person, but instead we took turns sharing the work. The person in charge of a particular document consulted the group for help in writing it, but ultimately was in charge of assembling and submitting the document.

One member of our team suggested using C# and the Microsoft .Net development software. Although we do not have much experience with many other languages, C# worked well for what we needed. It was not too difficult to learn after already knowing C++.

If we were to do another project in the future, we would put a little more time into designing the overall system architecture and the interfaces between the units before starting to code. Also we would divide the project a little differently, putting more people on the GUI interface and more on learning how to import a DLL or COMM object into our software.

In addition, we noticed several good ideas that other groups came up with that we had not thought about, so I would recommend spending more time brainstorming ways to make our software more user-friendly and competitive rather than implementing our first idea and deciding we were done. We could have consulted our customer, Dr. Jones, more frequently to determine what he would have liked to see in the software.

Finally, I would suggest investigating some file sharing software that could store different versions of the document and make it easier for us all to be working with the most recent version. One group recommended using BitKeeper, and I would be interested to see if that software would help us out. Submitting all change requests to our lead programmer became tedious for us and burdensome for him.

Despite the challenges, working as a team was interesting, educational, and fun. We even held our last team meeting at Cinefour Theater with pizza and doughnuts. We gained a better idea of how group programming works in industry and how it differs from the small individual projects we do for many computer science classes.

Project Evaluation

Group C

CS 2370

This project was a great experience. I think that my grades suffered in every other class due to the time this course took and the obsession that I had over the project.

Working with a team in trying to develop software was a new experience for most of us in the group. It was a difficult process simply to agree on a common architecture and decide how things will work. We did lose two people over the course of the semester, which made things difficult, it is hard to recover allocating more time to complete sections you expected some one else to complete.

Good Things we Did:

We used CVS, and it was a lifesaver. It would have created a lot of extra work if we had tried to combine our code changes manually using FTP or other means. I believe the entire group would agree that using a document version system is a good idea. We used a linux server on a DSL line with CSV installed and just used SmartCSV foundation version as our client.

Every one contributed to the project (except those who dropped out of the group). Other groups in the class had people who worked in the industry and not every one was involved in the application development. No one in our group had any idea what we were doing. It was very challenging in this respect, but it was a great experience.

Working together in the lab as a team on code. The code quickly became very complicated and as we were trying to integrate all the different parts it would have been much more difficult had we not all been sitting next to each other, able to easily communicate.

Exerted a lot of effort on documentation. Many of the other groups did not score well on documentation, I believe that we were generally the high score (the documentation is worth a lot of points!). This also paid off when we actually started coding, because we all knew exactly what we wanted to accomplish.

Problems We Had:

We didn’t get any code done until 5 weeks before the end of the semester and nothing substantial until 3 or 4 weeks before. Starting earlier would have helped us in a lot of respects:

C# C++ Incompatibility. We originally developed the basis for some of our code using C# and one week before the presentation for the class it became apparent that we could not access a C# .DLL file from MSVC++ 6.0 executable. It seems like we would have caught this earlier if we had created some code.

None of us had ever created a thread, realization that a lot of research was necessary to implement threading in the code didn’t become apparent until after code was coming together.

What Was Most Useful:

Google was very useful to search for information on the many topics that we didn’t know about. Also CVS was very useful for us as it allowed us to access our files for the project at any time as well as all of us being able to work on the project at the same time.

What Would We Do Different:

If we had to do this project over again we would have gotten executable code sooner. But the fact that we had spent lots of time on documentation made it possible to get the code going quickly. Also we would have made sure that all members of our team were working on the project and didn’t drop out on us. The two people in charge of our sorts dropped out on us so we had no one to work on the sorts until the last minute.

Post Mortem

Group D

What did we learn?

We learned the various steps involved in the process of software development. We learned how to work together in a group, how to delegate responsibility, and how to function as a group. We also learned how to research and learn techniques that we had no prior exposure to, such as animation.

What worked well.

Documentation and research. What we didn’t know about animation in Java we found examples and tutorials on the web that educated us on the process. Regular weekly meetings also helped keep the group on track. We always knew what documentation was due next and would be thinking about it ahead of time. A well laid out project plan helped us to see where our progress was at and how much time we had to do certain tasks.

What didn’t work.

Having some members of the group in the dark as to certain details of the project. It wasn’t until the end of the semester that everyone in the group obtained Java software in order to run and test the software. Up to that point, some of the group wasn't aware of the progress/problems of the project. This was especially true when parts of the group were more focused on doing paper work. They wouldn’t be aware of the progress of the programming.

What was most useful.

Having an ftp site available 24-7 (constant communication). This allowed the main programmer to post current versions of the program for the rest of the group to test, and the other members of the group to post documents or research they had performed.

What we would change.

Having the whole group participate in the programming. We chose a programming language based on what we thought would perform well for the task. What we should have done was pick a language we all could’ve worked on, or at least had those unfamiliar with the language learn it. As it happened, there was only one person familiar with Java and we just fell into the situation where he programmed everything and the rest of the group did documentation and research for the programming. If everyone had taken a month and learned Java, it would’ve (1) helped out the guy who did all the programming, and (2) given more perspectives and ideas to the programming process.

Team E

Project Evaluation

What we learned:

From this project we learned that software is much more complex than we could’ve imagined. We learned how important it is to work as a team. We learned that setting deadlines and sticking to those deadlines helped us to get more accomplished in a shorter amount of time. Finding the right tools for the job is vitally important. We also learned that we still have a lot to learn before we head out into the big world of programming and engineering.

What went well:

Well, I think that one thing that went really well for us is our documentation and other papers that were turned in early in the semester. We were able to divide up the tasks fairly uniformly and produce some high quality documents. The other thing that worked in our favor is having somebody who was very familiar with Visual Basic.NET in our group. This made making the GUI much easier for us. We had two people do the majority of the programming. This was both a benefit and a problem. Some of the benefits that we got by having the programming done centrally was that communication was very simple between the two programmers. It was quite easy to keep track of changes, since only two people were changing the actual code. This also allowed many of the other members of the team to focus on the documents that we had to turn in and also on the documentation. Another benefit is that whenever there was a question, we had two people who had a really good idea of what was happening, instead of having 8 people with a good idea of what was happening in a small portion of the program. Our group ended up using the “Chief Programmer” group organization. This worked well for us. Another thing that went fairly well was having the latest version of the code posted on our group’s website. Everybody gave 100% on the assignments, and we all enjoyed the friendships that we formed, and the knowledge that was gained through those friendships.

What went badly:

One of the major problems that we faced could’ve also been seen as an asset, but we had 2 people do a large majority of the programming. This caused some problems because towards the end of the project, those two individuals had to shoulder a lot of the burden of meeting on weekends and coordinating who had the code. Another problem was that nobody besides the 2 programmers knew VB.NET, or had ever coded anything with it. At the beginning, we anticipated having group members code the sorts and put them into a dll, but that proved to be a somewhat challenging task, and not quite as simple as we had previously though. This caused us to code the first few sorts in Visual Basic, which meant that only the two programmers knew the language. Then, by the time that we got to the point that we could’ve had other team members coding the dll, roles had already been pretty much assumed and that continued for the remainder of the project. Another problem we had was that our website crashed pretty hard a few days before our testing document was done, so some group members were unable to access it.

What was most useful:

The most useful thing that we did was switch to VB.Net early in the project. This language and development environment really helped us to accomplish a large amount of progress in a very short time. There are also lots of special features and tools in this new environment that made using graphics very simple. It was very simple to create a very professional looking GUI in a very short amount of time.

What we would do differently:

If we had to do this project again, I think the first thing that we would do is either choose a language that everybody knew, or a language that nobody knew. This would allow the group to either split the work up, or to learn the language as a group so that there wouldn’t be anybody who was “ahead of the curve”. This would allow us to have more people working on different things at the same time. I think it would have allowed us to do more features than we did in this version.

CS 2370 Group Project

Team F

Project Analysis

Difficulties with Assignment

Lacked a clear procedural vision at beginning.

No particular expertise in type of programming.

Hard to develop common vision.

Problem difficult to parse into individual assignments.

Procedural Difficulties

Meeting / Communication Difficult

Meet in Lab.

Access to FTP site sporadic from lab.

Overlapping parts, dependencies.

Inexperience with design.

Loss of team members-- 25% attrition rate.

Infrequent meetings & communication.

Other things going on.

Strengths

Good at communicating problems.

Strong team players.

Everyone completed assigned tasks.

Work completed on time.

Quick to learn and adapt.

Work was high quality.

General Critique / Analysis

More difficult than in corporate environment.

Problem would have been easier to do alone.

Trying to do two things at the same time – learn methodologies and complete project.

Team not unified in purpose.

Group G

What went well, as well as proved useful:

There were many things that seem to work good for our group. After our first meeting, we tried to organize ourselves by assigning roles. This proved to be a great advantage as we started early. We had one person assigned towards the sorts which was a great asset because he knew everything about them. We tried to make everyone master of their own domain by allowing them to figure out the best way to organize and design the modules of the system. Our sort programmer proved this to be a great decision by making some great decisions on his own. This also proved to be a good idea as the programmers were given more freedom to write the code how they wanted to, which proved to be rather effective. Our other key programmer who knew Open GL was very helpful in setting up a repository called Bitkeeper in people’s house. This allowed key upgrades on the versions to be constantly distributed throughout the system. We had constant communications throughout the project by email and instant messenger as well as talking to each other after class to set up meetings. We thankfully had hard workers so the work was always done and done good because each person put in more than just the standard amount of work by really going the extra mile. These keys allowed an effective production of an excellent product while having lots of fun doing it.

What went badly and how we tried to change it or would change it for the future:

Well, now that the project is over, there are lots of things to be learned. First of all, DOCUMENTATION IS NOT TO BE UNDERESTIMATED. At the beginning, we assigned only one person to documentation which we soon learned would not be enough to get the scores we wanted. We were able to change this by assigning more people to it later. We were poorly organized because we truly didn’t understand what part of the programming would be the hardest. We knew the graphics and GUI would be hard, so we estimated that. We learned in class that testing can take up 50% of the programming so we assigned 2 people to do that. The problem with this is for 4-6 weeks, the testers have nothing to do. If we were to do this again, I would definitely assign them to over-viewing the documentation as it would prove to be a key improvement. The documentation proved to be more than 75% of the total grade so this is the key to getting better grades. Also, we learned that we truly didn’t understand the requirements of the documentation. I would recommend more association and communication with the teacher to double check the reports before they were submitted. This helped later after we learned the hard way from not so great scores. After we changed this, we found that our documentation scores were perfect. Lastly, make sure that everyone truly understands the repository software. We had lots of problems trying to learn how to upload the changes in Bitkeeper but with some personal one on one help this was quickly overcome. All in all, the problems were minimized after we recognized them through our contingency plans and just plain smart thinking.

Team A

Project Evaluation

What did we learn...

We learned the importance of team communication and team meetings. We also learned about how important it is to have a repository for the different versions of the code so that everyone has the most current version and changes aren't made redundantly. It was also very helpful because people could include comments of what changes they made to the files. We learned the importance of contingency plans. We also had the opportunity to learn other languages from people who knew them. Deadlines and milestones helped us to keep us on track rather than being a burden. We need to have more interaction with our customer so that we can make sure we understand the requirements. In conclusion I think one of the most important things we learned was to go outside of our roles to help others with their projects.

What went well...

Getting together to code and to test others code really helped us out to get immediate input. This also allowed us to make changes immediately and verify that these changes were correct. This saved immeasurable time having to do all of this by email. Also, having a code repository worked really well. Our contingency plan was needed and it worked very well for a rapid prototype. Rapid prototyping worked out really well for us. We then were able to use the basic ideas developed to come up with a much more efficient and robust version. Meeting together as a team very often helped out a ton too. We also got along very well as a group. We also used the experience of everyone to accomplish separate tasks such as GUI implementation, animation, and C++ coding.

What went badly...

Lack of access to certain developing environments such as Delphi. Another thing that didn't go so well was only having one person really know Visual Basic so that others were really unable to help make changes to this. One other thing that really hurt us is that some team members were unable to access the repository at all times. This really seemed to cut us off. We felt that there really wasn't enough time at the beginning of our project to create a good specification. This would have made for a better allocation of resources later on.

What was most useful...

The repository was extremely useful as well as the message board. Just to let you have an idea of what the repository was like here is a link to is. http://cs2370.cJb.net If you go to the link at the left called repository you can enter the login name: jones and your password is doublejones Laptops came in very useful. Companies allowing us to use trial versions of their software. Access to the on-school computer labs even after hours (at the expense of Zack's job).

What would you change...

Formal source code control such as knowing on the repository who had checked out the last version so that we could know who had it. Also, being able to checkout multiples files at the same time from the repository. We definitely would have put more people on the GUI aspect of the project and less people on the algorithms which ended up being relatively easy to implement. We would have started working on the backup GUI earlier to avoid several sleepless nights of programming in succession. We would have brought a laptop when demonstrating our project to the class.

Post Mortem

Group B

What we learned:

Probably the most important thing we learned was that nothing should be left entirely to a single person. In our situation, one of our team members was to be responsible for the graphics associated with the project. The person assigned to learn and program the graphics portion of our project did not complete the course. The rest of us were left to scramble for another solution to the problem with only four weeks remaining in the semester. Looking back to the beginning of the semester, there were symptoms of the problem much earlier. It seemed that no progress was being made. We addressed the problems with the individual and were assured that everything was fine. We should have taken more aggressive action in response to these warning signs.

At the beginning of the semester, we did talk about what risks our project would face. Some of them we considered to be very small and did nothing to minimize their impact. We have learned that even if a risk seems small, unexpected things happen and every risk should be considered a serious one.

Our team faced some difficulty with version consistency of documents and code. Important design decisions were made at some of the meetings. Because not every person on the team was at the meeting, when it came time to implement something, there were consistency problems. Members of the team who were not at the meeting did not fully understand the reason for the decision or the impact it would have. We learned bow important it is for every member of the group to attend the group meetings and to work in accordance with the decisions the group has made.

What worked well:

The thing that worked the best was that a majority was committed to the project. We pulled together when it was important. Also, that we assigned things to be done by group members. Another thing that worked well for us was route of communication worked. We used E-mail to communicate for the most part. We did however get everyone's phone number, but that was on a basis of need only.

What was most useful:

One of the things that was most useful was the creativeness of the members of the group. When a problem arose, we were able to get the problem solved now and not later. When the head of the graphics dropped the course, someone in the group had already started something before being asked to do so. Another thing was useful was the help file wizard. Once that was compiled adding it was very easy. One of the biggest helps was that everyone had knowledge of C++ so that they could read and understand code written by everyone else. Our deepest thanks goes out to Mark Salisbury, President of ACM, for the help that he gave to Julie with the GUI.

What we would do differently:

If we were to begin the semester and the project again, we would take into consideration what we have learned in the last few months. First, when we made job title assignments at the beginning of the semester, more than one person would have been assigned to each job. This would have been better for balancing the work among the members of the group and would have helped us to avoid problems that arose later.

We would also be more aggressive in taking responsibility from those that were not performing their tasks. If there were more than one person assigned to each task, changing and modifying assignments would have been much easier. As it was with only one person assigned to a job title, it was very difficult.

A central store of code and project documentation would have made communication easier. All of the groups that used some sort of central store of information, such as an ftp site, say it helped them avoid version consistency problems with the code and the documentation.

We would do more of the work as a team. Between class and work schedules, it was difficult for our team to meet together. Often after a short meeting to divide and assign work, each member of the team was expected to complete their part of the deliverable by a decided due date. Because of this, we sometimes had problems meeting deadlines that we set for ourselves especially if one part of the deliverable depended on another. Working together as a team would have helped us meet our deadlines and to have more consistent documentation.

Summary:

Despite obstacles, our team was able to able to build a graphical representation for the graph and a user interface. We were able to combine components of the project to make a working product. All of us feel that a little more time would have allowed us to work out the remaining bugs. The next project any of us work on will have a better process and will result in a better product due to the knowledge and experience we gained from this one.

Team C Hydra Project: The Aftermath

Project Evaluation

WHAT WORKED

Team C was by far the most effective during tasks in which there was a good and predetermined distribution of work. This was true for homework (deliverables), program coding and documentation, testing, and the final presentation. Based on our experience, one person, faced with a single task, will complete it more efficiently and with greater creativity than a group all attempting to work together on multiple tasks. Specifically, if each team member was given a small part of an assignment to complete before a team meeting, it was always a simple matter to take completed parts of the assignment and join them into a whole. The principle of subdivision of tasks was also apparent as it pertained to team members' willingness to fulfill their, assigned roles (manager, designer, toolsmith, etc.). During work in which each team member asserted himself in a role, the Team C dynamic was streamlined, organized, and efficient.

WHAT DIDN'T

Of course, when Team C did not follow the principles outlined above, things didn't go so well. Assignments were rushed, often completed at the "last minute," and of low quality. Meetings lasted hours longer than necessary.

Occasionally, a team member would fall to complete a given assignment before a meeting, forcing the team into an inefficient "recovery" mode.

Another costly failure for Team C was its neglectfulness in following the Software Engineering principles it spent so much time researching for assignments and deliverables. The bizarre situation which arose during the final Hydra demonstration for the instructor should have been avoided. The fact that Hydra was far more complete and functional the night before the demonstration than it was during its test with the Instructor the next morning, will always be remembered as both unfortunate and completely unnecessary. Had the team held to the requirements, specifications, and diagrams it spent so much of the semester creating, there could

have been no confusion about the code at the last minute. The damaging changes made to the code in the final 12 hours before demonstration will always stand as a costly reminder of the importance of the engineering process.

Group D

Our group learned a lot through having this experience of designing and implementing a GraphADT. One of the main things we learned is that communication is vital when working with a group. Things don't happen and progress is halted when the teammates do not talk and communicates with each other. We also learned that a successful team requires dependable teammates that never give up. One needs to be able to count on their teammates to do what they agreed to do, even if it seems impossible at the time.

When it comes to the program itself we learned that no matter how many errors you find and resolve there will always be more that you never foresaw. Finally, we learned that the display of a program is very important in the overall presentation of the program. T he display makes a big difference in the usability of a program.

Throughout this semester many things went well for our group. One of those things is that we had a scheduled structured meeting every week. We discussed group goals and ideas and then moved on to helping each other with our individual tasks. We set up a yahoo groups e-mail account to make communication a little easier. This would allow us to send one email that would be received by everyone in the group. At one of our first meetings we established style rules for our coding. We thought this was very helpful because it saved us a lot of time of not having to format everyone's code the same at the end. Lastly, we felt that we worked well together as a team. If we disagreed about something we would resolve it and it would not longer be an issue.

We also had some experience with things not going well. One of the main things that we felt did not go so good was that we did not exchange phone numbers in the beginning of the semester. We felt we could have been a lot more productive in the middle of the sernester if we could have communicated via the phone. We also felt that it was a disadvantage to not present our prototype to our customer to make sure we were building our product right. We would have preferred better clarification on some of the requirements.

There were several things that we felt were very useful to us as a group. The main thing was the email group. It saved us a lot of time of sending emails because all we had to send was one. We also felt that the architecture design of our product was very useful when it came to implementing the algorithms. The design was done very well so that it made it easier to implement the rest of the product. We also felt that it was an advantage for our group to have some knowledge of MFC. Finally, the most important thing was that we had a team that was very willing to help one another. Everyone tried to help out where they were needed and not just very focus on their assigned. task.

Finally, we felt there were several things we would change and do differently next turie as a group and in our product. As a group we would have more than one person working on a task incase a teammate was lost. This would help us to still have someone that understood what the lost team-mate was working on. We also thought that the use of instant messenger would enable better communication. In our program we thought we would add the following features: undo/redo, printing capabilities, explanation of the algorithm boxes, and lastly to fix some minor

details with a few of the algorithms.

In conclusion. we felt that this experience taught us a lot about working in a group. We felt that this experience has better prepared us for the future "project groups" we may be in, whether it be in school or industry. We feel we have a better understanding of tile development process of software engineering.

Team F

Project Evaluation

Perhaps the biggest thing we learned was the necessity of assignments and following up on them. If deadlines are missed it affects the rest of the project either to the delay of it or even making it so it isn't completed at all. The need of team work is also very important. If the team isn't getting along then the work doesn't seem to progress. We did learn the need to have the interfaces and requirements very specific so there is no doubt. It is easy to think everyone else will do something a certain way and when you come to integrate they don't work.

What worked really well was the group emailing and the code repository. They helped us to keep in touch. Also we always met every week at the same time so everyone knew when we had the meetings. What went badly was the trying to get all the code modules that were assigned out completed. It resulted in us not having a totally finished project and delayed testing.

What we would change next time is to have all programming done in teams. That way no one can put it off and if someone doesn't show up we have the other person at the meetings to understand the decisions that are made so that they can be implemented in the code. Also it would allow us to better evaluate the project progress to have two inputs from every aspect. That would help us better know how to allocate man hours.

In general we have learned that the real world of programming is very complicated and the interactions of a team can really make or break a software product.

What did you learn:

While I learned a great deal about programming, message passing, and other useful programming techniques, I think the most important things that I learned from this relate to how I worked with the group. I learned the importance of schedules. I learned that planning ahead can save a lot of time, but it's only really effective if you know what you're doing. Having done this project, I feel that I will better know what to plan and how on any future project.

What worked well or badly:

What worked well was the group's work ethic. I feel that everyone was willing and anxious to contribute everything that they could. We really didn't have any conflicts among ourselves and I feel that was a real boon to us. As for what didn't go well, even though we produced the deliverables necessary for the class, I don't think that we got as much out of them as we could have. I also think we could have used everyone's abilities better and not relied so much on a few people who were more experienced as much as we did.

What was most useful:

I think that producing the user's manual in advance, while it seemed odd at the time, was probably the resource we consulted most to determine how things were to be done. If we had added more detail and stuck better to it's description, we would have probably finished in less time.

How would you change next time:

I think I made the mistake of assuming too much about others abilities, real managers have the advantage that they have access to each employees resume and possibly work record, at least inside the company. Balanced teams that allow everyone's abilities to be exploited are really the best way to go. It would have been nice to have had this information available from the first when we made our sub groups. I would also use the documents we produced more and while I can't exactly say how, I'd know better what to put in them.

Project Report

Working on this project, I have learnt plenty of useful things. I found that a good "communication" is the most important thing on "group project". Definitely, we cannot complete every single task by our own. We have to work together, as a team! Besides, I learnt more on GUI interface and animation. As I only know how to create functions and classes in C++ before. Now T find more fun in Computer Science. But I was really sad about one thing. That is we cannot finish some of the parts in time! That means we were not synchronized and could not integrate different parts, even somebody have finished my parts a long time ago. So we just waited and waited. But I knew everybody is busy too

So next time, before everything gets started, we must to create a working schedule.

We should be more responsible on our and the whole project.

Anyway, I really enjoy this chance of creating software in a group! This is really exciting and making me feel good to look at our final project!

Project Report

The most important thing I learned in the class is communication. It is very critical part to create high quality software. We divide our group into three teams, animation team, GUI team and Graph source code team. We met almost once in a week through this semester. It was really good for us to work together and to know what is going on in another teams. The thing we can improve about group meeting is that each team should prepare for the purpose of the meeting and spend more time on discussing and exchanging opinions each other instead of putting time on doing their own teams job in there.

Secondly, I realized that it is very important for us to have a good planning of system in detail in the very beginning of the semester. We should create goals for very month so that we can integrate every sections code or discussing the logic of each team constantly and find out bugs, misunderstanding between teams, things lucking and so on. It seems like we paid attention on own team's part heavily, and it happened sometimes that we had to restructure some works again.

Planning our system well, creating appropriate schedule, exchanging opinions well and making document for each one of them are things I realized them important. If we change something on planning, schedule, I thing we should make a document so that we can keep truck of every changes and make sure responsibility of individuals.

I will put importance on those things I learned in this semester and want to improve the process of creating software next time.

I found this project to a very educational and enlightening experience. I have gained a lot of insight into how much effort and communication is required to develop even the simplest pieces of software. Also, software complexity does not stop at the coding level. Organizing your team, designing the product, writing specifications, all the major aspects of the development process are just as complex, I think, as the actual coding. Once you actually get to the coding stage, converting your specifications to code is easy assuming you have done a quality job in the previous steps. I understand now why making accurate and comprehensive specification documents in the early going is so important to the success of the project.

I felt that our team worked well together when we met and that meeting once or twice a week was an adequate amount of meetings, mainly because our schedules were so dysfunctional. We never had any major arguments about anything and were able to communicate Our ideas and thoughts in a rational and well thought out way, which made our meetings go smoothly. Unfortunately, we had a hard time meeting in the same spot and same time every week because conflicting schedules. This made it hard to remember when meetings were and frequently individuals showed up late. Also, our meetings lacked agendas, which could have increased the productivity at the meetings we had. I think that if at the end of each meeting we had mapped out what we needed to talk about in the next meeting, our project would have gone better.

If I had to do this project again, I would make sure that we met in the same place at the same time every week and that we had an agenda for every meeting. Also, the absence of Li code repository for our documents and code made keeping Lip oil the most current code very hard. I would set tip an FTP site for this purpose where we could keep our code and also exchange ideas, via a forum. Lastly, our specification of interface interaction would be much more defined very early on so there wouldn't be so much confusion about how things were supposed to interact with each other.

I have learned a variety of things working on this project. Aside from the technical things that I have learned like Visual Basic, and windows message passing, I have learned a lot about software engineering. As I have progressed through the semester I have also learned things that if we were to redo this project I think we would do a bit different.

One thing that I think that we would change would be to make sure to thoroughly define our interfaces between our components. We ran into problems that could have been avoided if we had more concrete definitions of the product and the interfaces. Part of the problem was that we didn't have a uniform understanding of what we were doing and how, and if we had been uniform our thinking things would have worked much nicer.

A big help to our project would have been to have a single repository that everyone Would have access to. This would have facilitated our exchange of information and code. With easy access to code we could have had much more current versions of the different modules to work with as we worked on our individual parts.

Though there are things that I feel could be changed if we were to try again to create this product, I still feel that our group worked together well and we helped each other out a lot. Our group moral was great, everyone worked hard, and we also had fun.

Over the course of the project, I learned and struggled with learning a new language, and adapting it to work with a Visual C+4- program. Learning Visual Basic 6 was fun for me to learn. I have been eager to learn more tools of programming. I have found that Visual Basic is easy to teach yourself how to use for the most part. Syntax and debugging were made easy by the program itself The hardest part to learning Visual Basic was learning the advanced methods of programming and poorly documented functions that are built into the editor. One complaint that I have is, C44 may have been easier to use because I already know that language for the most part. Staying with a language that I knew might have saved us time in the long run.

Although Visual Basic was fun and mostly easy to use, the project was not something that I could just walk through. In the beginning, I volunteered to be the facilitator and keeper of all documents. I would do my best to help set up meetings and remind people of when we were to meet. At each meeting, I would keep minutes and bring up issues from the last meetings. This was easy to do, when we had productive meetings. One thing I would change in our meetings would be a more productive meeting structure. We would meet and get distracted by topics like sports, computer games and other fun things. I feel we would have spent less time in meetings and more time working if we were more focused in our meetings. We still had productive meetings, despite the excess of fun we would engage in during the meetings.

One of the few things that I did not really feel comfortable with in the group was the difficulty that I had to go through to get a hold of group members. Most of the time I could just see them in class. But there were times that I would have liked to be able to call them and ask questions. It was not until this last week that we made a phone list. Email is nice, but it is useless until the one you need to talk to checks their email. If I were to do this again, I would have set up an easer communication network

I conclude that the project was a worthwhile endeavor that I am happy to have been able to participate. I feel I learned many issues that were brought up in class discussions better because we implemented these ideas into our group work. I would do it again if the opportunity ever came up.

What did we Learn?

How to program in java ... go beans!

The importance of interfaces and of interface design early in the project.

The annoyance of the documents but their helpfulness.

What it takes to put together a large scale project.

How important scheduling and risk management is to the completion of a big project.

How important testing and test planning is to reliable software and to help in debugging.

We needed versioning software.

What worked well or badly?

Given a sufficient number of computers, it worked good to have all programmers in one room.

A good division of labor worked well but we needed clearer layout of interfaces.

Having an ftp worked great, but sometimes things got lost.

Java and all its documentation and structures helped a lot.

What was most useful?

Having a downloadable compiler and Ethernet to access it.

The Enterprise Architect was very useful in drawing UML diagrams and could have generated code for us.

Email was very good when mailboxes were not overloaded.

Change?

Better design earlier in the project.

Teach better risk management for loss of resources.

Stress interface design early in project.

More help from professor

What did you learn?

We learned that a software project is more than just code and an executable. To complete a software product, it includes a number of deliverables. We learned what these are.

We learned that teamwork is a must. When a team member is assigned to do a task and they are not able too, other members of the team must step in and pick up the slack.

What worked well?

Another advantage we had was ad hoc communication. When changes were made, we were able to quickly make everyone aware of them and re-focus our efforts.

We also had a weekly meeting where we would meet and update everyone on where we were and make assignments to each person.

Another thing that worked well for us was to have access to the ideas and thoughts of the USU Facilitator at our site. When we had questions, we could go to him.

What worked badly?

What was most useful?

Of all the things that helped our team, the things that were the most useful were as follows.

(1) The ability to communicate and have regular meetings to keep the project on track was very useful.

How would you change next time?

We would focus on better time balancing so team members are not spread too thin.

We would keep more accurate records of time and contribution to the project.

What we learned:

As a group, we learned the value of requirements gathering. We should have been better at approaching the professor as the customer and gathering requirements regarding the deliverables. We also learned to communicate regularly. By keeping everyone informed, we were able to handle problems quickly and adjust responsibilities as needed.

What went well or badly:

The process went well altogether. By selecting a project that we were all familiar with, it was easier to keep everyone on the same page. Group members were then able to focus there time on meeting the deliverable requirements instead of trying to determine what everyone else thought.

The requirements gathering went poorly. We suffered on several assignments because we expected the professor to detail all his expectations, but he expected us to gather them from him. The distance education problems factored into this and caused some difficulties communicating. We were able to communicate with team members utilizing instant messaging, and a team user group we created. Unfortunately, one of our team members dropped the class halfway through the project, so we had to adjust workload and carry the extra burden.

What was most useful:

We found the use of a team user group very helpful. Most portals (MSN, Yahoo, etc.) allow the creation of user groups where you can limit the members, and post messages, links, documents, pictures, etc. This helped in communication. Also, we all established AIM accounts, so we could instant message each other throughout the day. The more team members that are located at the same site, the better. We were able meet ad hoc before and after class in order to ask questions and follow up on deliverables.

What to change:

We should have started earlier in the design process. It was difficult to know what form the deliverables would take, and what was expected. The requirements should have been posted, instead of taken from textbooks that the groups may or may not have. If we had had a better idea of what the deliverables really needed to be like, we could have gotten ahead of the game (no pun intended).

Summary:

For the most part, we enjoyed the project. The asteroids game was a good selection, as we all were familiar with the game, it was fun to develop, test and play, and it was fairly straight forward from a development standpoint. We struggled through many of the problems that are typical to software engineering projects. This gave us the opportunity to evaluate methodologies and approaches while in the middle of actually applying them.