This is an Sample project reflection on a course.
When we first learned how to write programs we did not really think about how we were going to accomplish it, we just started programming; only when we finish coding the first part, we think about the next part. In large projects, this could lead to a closed way. For example if we followed this strategy in large projects and we done one of the first parts wrong, we might need to start all over again or do a lot of changes just to fix that part. That could cost a lot of time, money, and work. That is one reason why every software should be analyzed and designed before coding-at least in projects that are relatively mid-sized to large projects.
Another benefit of designing is that it is most likely that more than one person is working on the project. So, designing help the teams to clearly understand how the project is going to be implemented. Designing also helps them to communicate and share ideas for the project.
To make sure the software will be developed to satisfy and cover all the requirements given, the designers can explain the design in a simple graphical way to the user or the one who asked for the software. If the requirements are incomplete or different, the designers can modify it easily before it is implemented and it is too late.
Also if a new programmer is hired, she/he can understand the project by looking at the design and join the team.
Before releasing the software, testing is also very important to make sure that everything is working as wanted. Testing is specially important after each iteration to make sure the part done is working well before adding it to the project. If a part has some errors then it is easier to fix that part than to fix the whole completed project. That is why testing is not less important than designing.
In our “Chitty-Chitty-Bang-Bang” project, we first brainstormed what is the conceptual classes that we are going to need in order to develop the game. Then we thought about how are they going to be linked to each other. To design the class diagrams we thought of the objects in the software as the objects in the real board game. For example, in the real board game routes 1 and 2 have a magic button each. So we designed a class called “MagicButton” and included an object of this class in each of routes 1 and 2. Since some players might reach route2 while others are still in route1 the first magic button could be different than the second magic button, which seems the best way to create it. Also, in each playerObject we created a carObject, just like in real board game. So, I think the best skill that I learned is to think in objects.