SE 371 Global Software Development
Monday, November 11, 2013
Week 9 - Tetris Implementation the SNAFU
During that week, we were assigned our designated tasks in trying to implement the systems for Tetris. My team was able to do our part correctly. I helped them out if they had any questions about XNA since I was the only one in my team who has a very extensive knowledge of it. However during the entire process, there wasn't really any other form of communication from the other teams on Piazza. There was some but it was very little. I was asked about what progress my team was making and I said that we were doing fine albeit I got very sick over the weekend during the crucial part of the implementation. However, I was able to pull through and get our stuff implemented and merged. However, there was a very big problem when I started playing the game on the very last day when we began to merge our code. Some of the crucial systems such as rotation and making the game go to the lose screen once the blocks have reached the top was not implemented. I don't know how the other team's collision code worked so I could not really help them out in implementing it. I guess it was the way I was raised I guess. I was very shy and quiet person growing up. There was a major communication SNAFU. I am also part of the problem for not speaking out about it. We did not really have an overall leader as to make sure people from each team got their things done on time. Hence, some of the major systems did not get implemented and personal emergencies that one person had to take care of. In the end, when we showed our game during class, we got chewed again by Ed about the lack of communication issues. I am starting to have a feeling that the way Ed formed the teams was that he grouped the very talkative types on one side and the quiet types on another side. We now have a better road map on how to get our systems working again.
Week 8 - The Tetris Planning
During that week, we collaborated with two other teams into implementing the video game Tetris using Microsoft's XNA Framework. We had a first big team meeting discussing what systems we need for the game. It was decided that it would be a first come first serve basis as to what teams can choose what systems of the game to implement. I was fortunate enough to pick out the easy stuff. However, I think that was not such a good idea. It turned into making one team do all of the hard and dirty work, which from a practical standpoint a very bad idea. When class time came to discuss our plan, Ed chewed us out pretty well about the very big holes we have in our plan and design. However, by the last half of class, Ed gave us time to collaborate with out team members to hash out an even better and more organized plan. That, I think was the whole lot better than what we had before. Let us see what will happen once we put our plan into motion. My team had to do the game screen manager (main menu, pause menu, and lose screen).
Wednesday, October 30, 2013
Week 7 Implementation of Other Team's Design
In that week, we implemented another team's design. It seemed to be pretty straight forward. However, there wasn't really any communication from the other team as to check up on our progress. I did make some prior communication with them, but it was dead silent after that. Maybe if we had asked questions to them then probably we would have gotten communication with them. However, I think it was both of our faults as to where there was a communication break down. There wasn't any problems in implementing the design. But I think it is very bad practice to not communicate with your remote implementation team to check up on their progress. In the end, we got the design implemented to their specified API and class diagrams. I am not sure if there was any quality assurance though.
Wednesday, October 23, 2013
Week 6 - Project Design and Planning
In this week, we planned out our design for the implementation of the Search List. We had meetings throughout that entire week discussing about what kind of data structures we are going to use for this project. We came up with proposals such as using a Hash Map table, fly-weight design pattern, using an array list etc. We kind of ran into some roadblocks, I would think, when trying to decide on a data structure to use. The thing we were worried about was about deleting a node and trying to compensate for the remaining indices of the remaining nodes on the list that we should update all of the indices of the list taking up precious computational resources. We decided to stick with a simple doubly linked list for our design. We had our Design API Document and Class Design Diagram up on our wiki site for the other team to use.
Tuesday, October 15, 2013
Week 5 - Unit Tests from HELL
We were given part 2 of Project 1 to implement. We are supposed to create unit tests for a provided open program. However, when trying to do the unit tests. I personally ran into a lot of problems. Besides not being able to have time to actually look through the code and being a complete novice when doing unit testing, a whole lot of the methods are considered to be private only. It makes it very hard to try and pick which methods to unit test based on the Cyclomatic complexity plugin for Visual Studio. Also, Cyclomatic lies to you about the actual complexity of a method. It does not say whether or not a method is dependent on a more complex method! And that dependent method could be private! This also made it very hard to try and unit test it. There was also a lack of documentation that came with the code project making it difficult to understand some of the logic behind these methods. Also, there was no overall plan by the designer of the program to understand what their vision for the project is. It was mostly was trial by fire and running around blind in the dark for this entire project. I learned a lot of harsh lessons from this project.
1. Do not outsource your unit testing to a third party without documentation
2. Only developers of the code should do unit testing because they would have a better understanding of their own code
3. If you are outsourcing your unit testing, be sure to have access to the original developers to the code to understand what they are thinking
4. Provide Documentation
5. Provide Documentation
6. PROVIDE DOCUMENTATION
1. Do not outsource your unit testing to a third party without documentation
2. Only developers of the code should do unit testing because they would have a better understanding of their own code
3. If you are outsourcing your unit testing, be sure to have access to the original developers to the code to understand what they are thinking
4. Provide Documentation
5. Provide Documentation
6. PROVIDE DOCUMENTATION
Sunday, October 6, 2013
Week 4
This week consisted of talking about how to deal with conflicts at the work place whether they were big or small. It was pretty interesting to see real world examples that Ed gave which consisted of a person being assault by a power transformer! We also talked about our teams and the planning for our project. I think our team's project plan is decent albeit where we have the choice of what methods we would want to unit test that fulfills the assignment requirement of going within the bounds of the "Cyclomatic" complexity. I have created two unit tests with one more being a work in progress and I still have to create one more which needs a complexity of 7 or more. I hope to be able to get this done by tomorrow. However, I ran into a snag earlier because my teammates were using the latest version of Visual Studio (I have Visual Studio 2010) which led to a conflict of the .NET Framework. I was forced to download Visual Studio 2012 and this fixed the problem. Everything seems to be okay so far.
Monday, September 30, 2013
Week 3
Well, we went over some Perforce stuff and also a little bit of the homework that was due last week. Then we covered topics about meetings, planning them, and also the effectiveness of them. After that, we then talked about technical designed documents that show what has been done to implementations that are part of the software development process. Ed gave examples of technical design documents when working on the video game "Stranglehold" during his time as Director of Technology of Midway. We saw the changelists and the problems encountered when trying to fix certain bugs that were encountered when trying to design the systems for the video game (ex. camera, shaders, etc.). It was very interesting to see these design documents and also gain a very deep insight in working with the video game industry. I also have my own team formed up. I am not going to be able to attend our first Skype meeting, but there are also other very important resources at our disposal (the wiki, Piazza forums) to hopefully make this very coordinated so that we could get the first part of Project 1 completed before Wednesday's class.
Subscribe to:
Posts (Atom)