Wednesday, February 29, 2012

Subordinate Role Project – Design Phase

What up! I’m back here with some updates.

So, the 2nd Project is over (we are actually quite into the 3rd one right now) and I will try to provide a small recap on it. This project consisted on two (2) phases: Design and Implementation. The idea for the first part of the project was for my team to come up with a design that satisfies a specification provided by the professor and then we would handle the finished Design Document to an Implementation Team (not my team) for the next phase. Likewise, my team was handled another team's Design Document for the Implementation Phase, but more on that part in the next post.

In our particular case we were handled the Spin specification. This requiremeconsisted in a large list of items that could be rotated (spin) between two (2) provided indices. When I say "rotate" I mean that all items inside the given range are flipped in their ordering. In order to illustrate this better look at following provided example:


Well, my premise for designing was keeping things simple and close to the original idea stated in the specification, so after some debate inside the team we decided to go with my proposed doubly-linked list mainly because it provided the following advantages:

  • Insertion (at the head and tail of the list) and removal of nodes can be done in constant time.
  • List can be traversed forward or backward starting from either the head or tail of the list.
  • Searching by node index inside the list can be faster since the operation can start from the end closer to the desired node.


I personally think we came up with a pretty solid and efficient design, and the package we provided to the Implementation Team was very detailed because it included: design overview, class diagrams, sequence diagrams, a suggested implementation schedule, test code and expected results.

Finally, and from the feedback we got from the Implementation Team, I can affirm you that my team’s hard work paid great dividends: the Implementation Team did not complain about the work placed upon them, and they contacted us no more than a couple of times (and were just clarifications), so this is how I would some it up “The more time you invest in producing thorough and fault-tolerant design documentation, the less time you will probably spend fixing possible bugs when the implementation phase comes in (support)”.

I will be back really soon with comments on the Implementation Phase of this project. Adios!

Tuesday, February 7, 2012

Unit Testing Project

What’s up everybody! I’m back with more cool stories about my Global Software Development class. This time I will talk about my Unit Testing Project. Prof. Keenan assigned groups based on our skill set (everybody in the class had to fill out an online survey) and the main idea is that you never meet with your teammates in person; you have to use all kinds of collaboration and communication tools to discuss and come to agreement with your team.

So for this project we were given a Physics Library written in C# and .Net and we (my team) were supposed to code some unit tests for it. I had done Test Driven Development before, but I have never actually written the tests myself, so I was kind of excited about this project since I was going to learn a pretty useful tool.

This project was divided in two (2) phases, so let me try to explain how they went:

The first phase of this project was all about Planning & Team Synchronization. First Julie, one of my teammates, proposed herself as Team Leader and we all gladly accepted. Next, we created a Google Group (forum/mailing list) to use as our main way of communication and we built a Team Wiki Page (Google Sites) to post team info, news, project development and announcements. Finally, we all had to go through the code using something called Cyclomatic Complexity and choose 4 different methods for each member to write Unit Tests for. Each one of the methods selected had different difficulties according to the value given by the tool. These were the methods I selected:
  • Basic (2): AdvanceMath > Quaternion > Inverse (line 562)
  • Intermediate (3-4): Physics2DDotNet > Shape > CreateCircle (line 88)
  • Advanced (5-6): AdvanceMath > MathHelper > RadianMin (line 71)
  • Expert (7+): Physics2DDotNet > DistanceGrid > TryGetIntersection (line 79)

The second phase consisted on actually Writing the Unit Tests. I didn’t know that C# and .Net had a library for doing this (another new useful tool for me, sweet!), but yes they do (Microsoft.VisualStudio.TestTools.UnitTesting) so kudos to Microsoft. The whole idea with these tests was to prove that the methods selected work as advertised, so we had to try and test their functionality using regular values and corner cases. Here is a screenshot of how Visual Studio presents the results:


Well, everybody in the team did a really good job and finished their tests before the specified deadline. So great work guys, this first project was smooth sailing. I hope the other ones go this way too. =D