[ This page is a part of the online guide Tips to Succeed in Software Engineering Student Projects    ]

As per the norm of most software engineering, this project took up more time and work than expected. Even though the overall task was not difficult, progress at times became stagnant due to miscommunication between group members. Different work styles also cramped development although it improved after everyone got used to working in a large group.

We realized the importance of Unit Testing and making sure that your code compiles (at the very least) before you send it to others. There were quite a few incidents when broken code were passed around, creating a lot of trouble and time-wasting for everyone.

This project has taken up a bit more time than expected; ... The chief cause turned out to be debugging.

It is sometimes quite difficult to work in groups. Occasionally, there will be some miscommunication between sub-groups. For example, when we were discussing on API, the other group misinterpreted what we needed and provided us with something totally obsolete.

The project was much more time consuming as I expected at first. Most of the time, we spent thinking of ways to make the system flexible.

Through this project, we gained a wealth of knowledge. Besides learning a new programming language, we also learnt about the many tools available out there which help us to increase our productivity. Although at first we were apprehensive about installing yet another host of programs on our computers, we later realized that we benefited a lot from these very powerful tools. We also learned the importance of sticking to a design plan and API as any major changes affected the rest of the team as well. We have also learnt the importance of a project planning and setting of internal deadlines. We realized the cascading effect of missing deadlines, which affected productivity and increased stress levels as a major deadline approached.

Constant communication has been of utmost importance in ensuring that the development of the application progressed smoothly with as fewer hiccups as possible. While discussions online and through email have been useful, it was the face-to-face meetings that have proven most useful in settling outstanding issues and miscommunications in the group’s differences in their understanding of the specifications. ... Breaking tasks down into smaller goals made it easier to know what are the key tasks and the components that need to be developed at different stages of the project. ... This however is not fool-proof – lapses and delays have occurred in meeting certain targets.

We learned that nothing ever goes perfectly as planned, and the importance of planning for some extra allowance in meeting certain targets. It is vital that each component of development be given more than ample time to be completed. While the group has worked hard at completing their tasks well and in a timely manner, several lapses in meeting our target time was inevitable. Often this was due to the need to wait for several other members to complete other tasks. 

We found UML diagrams to be very useful in better understanding the concepts and requirements of the project. Often during group meetings, even hand sketches of UML diagrams (such as domain models) have come in useful in better understanding how the application is to be developed.

 Unit testing alone has been useful in making sure each class functions as it should. However, it must be noted that much time needs to be spent understanding what each class does to make sure that we prepare the right tests for each class.

The need for version control was seen as a very important aspect of the project very early on in the project. We used SVN, which has also been very useful in keeping all group members up to date on the application’s development. However, it does not replace the need for face-to-face communication. During some circumstances, it was better to meet in person to resolve any clashes or misunderstanding in the code.

One of the problems faced were the lack of experience in C# and in most of the tools that were used in the project, such as Nunit, Resharper, Visual Studio etc. The only way to solve this would be to start using them frequently in order to gain that required experience with the tools.

The writing of test cases for unit testing is not as simple as it seems as most of the implementation is inter-linked and highly dependent. It is difficult to purely unit test an individual class’s method without using classes.

It was also not easy to accurately predict the exact and the types of methods we need from the beginning, a lot changes were made along the way. A lot of communication is needed between clients and producers on interfaces to converge to the right track. With proper integration testing and frequent coding session together, this problem was easily rectified.

This is far far harder than what I have done in any other project course, partly because this requires a lot more coding. It has been tough as we had problems with the time management.  However, on the positive side we enjoyed the group programming, and working in a group that shares the workload and share our ideas on how to deal with the problems we faced during coding.

Initially we faced some communication difficulties. Sometimes we had to pressure each other to ensure work is done. We made checking the Project Forum at least twice a day compulsory. Finding time for project group meeting to do group coding was not an easy task. We solve this by having common agreement (i.e.: All available time slots were submitted and matched) on the best time for a meeting. In addition, we frequently met as a group before our consultation timeslot to consolidate what we want to ask for consultation. We have smaller group meetings and online meetings too.

Overall, we are happy about how much we achieved at the end.

The highlights of the project include integrating thousands of lines of code from various group members into one working program and testing, to make sure that everything came together correctly. One of the first problems we faced was precisely this: integration.

After each section of code was done, we had to look at everyone’s contribution and copy and paste the different parts into one common file to integrate the program. Also, each new addition was uploaded to the forum, which soon became cluttered and messy with many files with the same name that differ only by the date. There was also one time where we needed to go back to a previous integrated version and we had no way to do so! This was solved after we switched to SVN, which came with its own set of problems, which was the high learning curve. We were initially puzzled by similar sounding terms like “update”, “import”, “commit” etc and it was disheartening to see a “conflict” window pop up when we tried to commit. The steps taken to resolve the conflict weren’t straightforward as well, having to open configuration files in Notepad and edit them by hand.

We also gained a lot of insight into the software engineering process, especially how bugs occur. Before starting on the project, we all thought that bugs either came from logical errors or syntax errors but this is not the case. Sometimes a bug occurs because a fix gets lost through poor revision control practices (or simple human error in revision control) as we are still learning, but just as often a fix for a problem will be "fragile" - i.e. if some other change is made to the program, the fix no longer works. Finally, it has often been the case that when some feature is redesigned, the same mistakes will be made in the redesign that were made in the original implementation of the feature. We would never have encountered situations where these arise if we did not work on a project of this scale.

Another problem was the correspondence between our documentation and code. Our code undergoes changes often and the corresponding documentation remains unchanged until we decide to update all of it at one go.

A major problem that we faced was that one group finished their iteration early and was sitting idle for few days while the other group was still working.

We also faced some minor issues due to a lack of central issue and bug tracking repository like Bugzilla or Trac, due to which email notifications was the only way to communicate and keep track of bugs found during the integration testing. Currently we have an ad-hoc solution in form of 16bugs.com. It is better to set up a central system, to streamline and make the process more efficient.

Other issues include inability to freeze the APIs early. 

Our team benefited a lot in learning from our mistakes we made earlier in the project.

Problems faced:
-Difficulties in adapting to new tools, such as NUnit, SVN
-Difficulties in agreement on API ( between subsystems )
The biggest difficulty is the development of API. Developing API requires developers to have thorough understanding of the system. However, sometimes due to the misunderstanding of the project description, API needs to be changed, which has effects on the system. This problem is solved as we involve more on the project, we have better understanding of it.

Problems faced:
a. Deadlines of deliverables were not followed closely. A lot of work was pushed to the last week. Pressure to meet the deadline resulted in rushed coding.
b. Optimal allocation of workload so that no-one is significantly overworked compared to the rest. Division based purely on subsystems is inappropriate because certain subsystems are more complex than others.
c. Most of the work was concentrated on integrating the different components into one system. This takes quite a large amount of time so it must be considered in planning.
d. Agreeing on interfaces between components and classes was done in a very informal manner, which is not efficient and also has a tendency to introduce bugs to the program. A protocol must be established by the next iteration.
e. Tendency to leave documentation at a lower priority
f. We should have planned to make deliverable datelines earlier, leaving more time for testing and integration of individual components.

The development of any application is as challenging as it is interesting. Our project being no exception to this, we did face some problems now and then.

One communication problem that was faced was discrepancies between the features offered by the API and those required by the API clients. This was overcome with a discussion session where in the requirements were clearly conveyed between the members.

Integration was another problem, as this involves respect for what others have done. Modifying other members code or structure without intimation is found to be disrespectful by most. However, this does happen due to the hurriedness with which programmers work. One such scenario occurred with the structure of SVN during our development. The existing directory structure was completely modified by one another member without any intimation to the SVN managers in the team. However, lessons have been learnt and such problems have been vastly reduced.

Overall, our project experience has been one of growth and understanding as we strive to achieve a common goal.

Problem:
• Integration of the system comes at a price of multiple bugs. This is due to the difference in coding practices and standards.
Solution:
o Ensure that a system of coding practice and standard is kept.
o Inform all members or members working at that particular code of changes to the data type or method parameters when making them.

Problem:
• Changes in main components resulted in having to change a quite a handful of code
Solution:
o Make early decision on the main structure of the code to allow easier continuation of coding.

Some advice for future students...
Learn how to write test cases to cover most of the code and find the bug.
Need time to get familiar with tools.
Spend considerable time on planning project and dividing task work.
Research and choose appropriate tools.
The project implementation should follow strictly on the timeline and schedules.
Meet 1-2 times a week for discussion and coding.