Friday, March 23, 2012

Blog3# Reflection on project development and software demo

According to one semester's effort in developing our software, I understand the process to develop a software in our real life, such as how a software life cycle runs in external companies and how to make product efficiently. In addition, I also understand how important the soft skills are to enhance our communication during the process. Especially, at the final software demo stage, effective communication helps us to demonstrate the functions and features of the software in a clear and concise manner.


In this post, I will describe the points I learn from the  project development and software demo preparatoin, and how those points might help me to manage my future projects better. The learning points I summarized are stated as below:

  • Expect the version 1.0 to be difficult. Version 1.0 software is all about dreaming! We need to create something that has never been created before. From setting goals for the team to trying to achieve them, we have several iterations of brainstorming and changing plans. Unfortunately, we also need to manage the project to meet the deadline at the same time. Even if we lay out the best plans, we cannot control the independent variables.  The problem is that while all these methodologies are great, there is simply no way to give a date to when software will be ready. Thus, I'm ready to expect the difficulty to create a software in the next project and expect changes for whatever reasons that could be.

  • Make to do list in a developer style. Along the way of developing the software, I realized it's necessary to list all the actions need to be done in a to do list and update it every week. However, the list usually is very huge if I list everything in one list and make me feel stress. In the future projects, as a developer, I should rank my work in different priority levels and then execute those actions in a systematic way without bringing more pressure to myself.

  • Get organized in advance. Before the final demo, we have weeks to prepare for these six minutes. In order to make a high quality demo, I need to practice a lot of things which include not only performing the script itself but also managing how to switch between actual software and PowerPoint slides smoothly. As what Benjamin Franklin said," By failing to prepare you are preparing to fail." Thus, preparation for work is also important for whatever I undertake to do.

  • End with an exclamation point.  Based on the experience of the previous two oral presentations, I understand it's important  to start a presentation on a high and also maintain the end on a high. The conclusion of a presentation is just like a great dessert at the end of a great meal. The entire presentation can hinge on the final impression I make which will take audience back to the key messages and bring our presentation full circle to the ultimate objective. After three rounds of presentations in this semester, I will be more confident in future presentations.

In conclusion, this is my first trial to create a product from design, proposal, implementation till the final demo. Although what I have done leaves much to be desired, it's a good starting point for me to apply what I have learnt in practice.

Bibliography


Kawasaki, G. (2006). How to be a demo god. California.
Miguelcarrasco. (2007). How To Kill Your To Do List, Developer Style! Retrieved 3 23, 2012, from Real World Software Development: http://www.realsoftwaredevelopment.com/how-to-kill-your-to-do-list-developer-style/




Thursday, February 16, 2012

Blog2# Reflection on CS2103T Project

For every team, there will definitely be challenges in order to deliver a good product. It doesn’t matter how talented you are, if you can’t manage your projects and problems, then you will struggle to achieve success.



Unluckily, our group's problem kicked in the first week because of lacking of manpower. Since there are odd number of students in class, our group was formed with three members only while other groups have four. At that moment, we have been aware of  how heavy our work would be.  Therefore, we seek for help from lectures and actively looked for the fourth member by ourselves in CS2103T forum at the same time. However, we did not get too many replies from forum, as by that time most students from CS2101 have formed their own groups while other students taking CS2103 are from Engineering Faculty and prefer to use C/C++/C# for the project instead of java. When we feel helpless and disappointed, we found Dr.Bimlesh  assigned us the fourth number Faizan Abid surprisingly and then our group leader Darren sent him an email for meeting. He quickly replied us, but unexpectedly again, he is on exchange program in Germany and will only come back after recess week. What's worst, he is good at C programming but not at java. By then we all feel like taking the roller coaster, ups and downs.



Although the problem tortured us for almost three weeks, we did not lose the faith in the project.  Instead, we meet up frequently and split the job among three of us. I can see that everyone shows his commitment to the project and positively work for the project design. According to the meeting yesterday, we decided that Darren will work on GUI design alone, Qin Chuan and I will take care of the coding of logic, and Faizan can help us do documentation and testing after he comes back. I believe this decision is an effective solution to the problem, although three of us have to suffer for the heavy workload.



With the solution I described above, we stepped into our coding stage this Thursday.  But my own problem kicked in when I started the coding for Venue Assistant. I realized that the information of each venue is fixed, because the name and number of faculties, departments and rooms won't be changed throughout the program. The only thing changing is the schedule of each room. Therefore, the fixed basic information has to be read from a manual written text file, but the rooms associated with schedule objects need to be written in a separate file which will be created during object serialization. I would like to suggest to give each room an unique ID and create a match function, so that room objects can be added back to department list according to the match function during the program startup. I'm also ready to adjust my proposed solution if our group members have a better way to solve the problem.



In conclusion, as the quote says ' The problem is not the problem; the problem is your attitude about the problem'. So far, we all work hard to overcome the problems we faced and have faith in what we are doing. I believe our attitude determines how well we do it, so let's keep it up and fight for our project!

Thursday, January 26, 2012

Blog1# Communication and Team Behaviour

We have discussed 5 most important attributes of an effective team player and 3 most vital qualities of a team leader in class last week. Beyond that, an effective collaboration team requires two more important elements: effective communication and team behavior.

Firstly, effective communication helps us solve problems, establish trust between each other, and create environments where innovative ideas, conflicts resolving, and important decisions can flourish. According to my observation during our group meeting , I summarized three principles of effective communication here. First principle is 'Practice active listening'.  Active listening can make the speaker feel heard and respected, which can help build closer and deeper relationship among team members. Furthermore, everyone can feel comfortable to exchange ideas, opinions and openly discuss issues in a creative manner. Second principle is 'Use nonverbal signals'. We can make use of nonverbal communication, such as body language, eye contact, laughter, volume, tone or turn-taking to enhance verbal messages that we want to express. Last principle is 'Quick stress relief'. If we are in the middle of a meeting and recognize that we are becoming stressed, looking for humor appropriately is a good way to take a moment to calm down. I believe managing principles of  effective communication will enable us to understand a person or situation better (Robinson, Segal, & Segal, 2011).

Secondly, effective team behavior is the integration of effective team players, team leader and effective interpersonal communication. Each element works both individually and collaboratively. As a team player, he/she can communicate constructively, listen actively, shares openly and willingly, cooperate, show commitment to the team. As a team leader, he/she is capable to make quick decisions, motivate team members and deal with conflicts. In addition, every team member including leader should be able to communicate effectively, so that the whole team can work together to achieve the same goal.

Last but not least,  I found there are two aspects that I can improve on to contribute team work better after examining myself. Generally speaking,  I'm an effective team member, who can respond to requests for assistance, put in good effort in team project, cooperate with  others to accomplish a job together and would like to share my information openly. To be honest, I 'm not a good listener. Sometimes I interrupt speakers to show my agreement or disagreement without allowing them to complete their sentences. Sometimes I may require others to repeat their explanation or questions due to not concentrating listening. The second aspect I can improve on is language. I realized the language barrier of intercultural communication does affect the effectiveness in discussion. For example , my first language is not English. I need to overcome language barrier to express my ideas accurately with a second language, which sometimes slows down our team's discussion progress by spending longer time in explanation to make sure we understand each other clearly.

To sum up, I will put my effort in improving my communication skills according to the study of module CS2101 and overcoming language barrier to contribute to our team in a more effective manner.

Bibliography


Robinson, L., Segal, J., & Segal, R. (2011). Effective Communication.
Thenmozhi, M. (2009). Group Behaviour. Indian Institute of Technology Madras .






Friday, January 20, 2012

Our first meeting for CS2103T project


Posted below is minutes of our meeting for CS2103T project today. After reviewing the content of today's meeting, I have to say we are amazing! As you can see, we've iendtified a clear purpose of this project, sketched out the basic structure of our program and cleared understanding problems with Dr.Bimlesh this afternoon. I'm glad to have Darren and Qin Chuan in the team and work together with them. They both have few years experience in programming and help me broaden my vision in analyzing problems during our discussion today. I hope we can keep a cordial working relationship this semester and try our best to design a good qualified product!
Happy Chinese New Year to all of you!
<> <> <> <> <> <>   <> <> <> <> <> <> <>

Analysis and Planning for CS2103T Project


Minutes

20/01/2012

13:20~14:20

COM2/108



Meeting called by
Darren-Gavin Ho

Type of meeting
Problem-solving, planning

Facilitator
-

Note taker
Zhang Xi

Timekeeper
Teh Qin Chuan

Attendees
Darren-Gavin Ho, Teh Qin Chuan, Zhang Xi



Agenda topics


 

1. PURPOSE OF CS2103T PROJECT

 

Discussion


  • Our program will be designed as a desktop utility, which provides a systematic solution for event organizer to book venue, plan event, calculate budget, broadcast events and receiving registrations from both facilitator and participants.

Action items
Person responsible
Deadline

-
-
-



 

2. REQUIREMENT ANALYSIS

 

Discussion


  • Model the process of organizing an event and sketch out the flow chart

  • Identify types of users: Organizer, facilitator, participant

  • Identify main functions of the program:
ü  Organizer: create, delete, modify events
ü  facilitator/participant: subscribe events
ü  Retrieve and display latest event information in user interface

  • Analyze the required information to create an event:
ü  Name of event
ü  Venue
ü  Time
ü  Content (flow of programs to be held in the event: time,programs)
ü  Budget calculator (items to buy: food, prizes, gifts etc)
ü  Facilitator (limit number)
ü  Participants (limit number)
ü  Submit/ Save as draft

Action items
Person responsible
Deadline

  • To research on the problems of organizing an event
  • To add in necessary functions based on research result
All attendees
Ongoing





 

3. SYSTEM DESIGN

 

Discussion

  • In order to apply OO techniques, we decide to store all the information in view of objects in text files and create a fold called 'database' to keep all text files, instead of using any database servers
  • Darren proposed to design the program with 3-tier model :
ü  GUI
ü  Controller
ü  Actual program code
  • Data structure : Array list

Action items
Person responsible
Deadline
  • Think about algorithms/computations
All attendees
Will be discussed in next meeting
  • To research on calendar implementation (flash, table or other tools)
All attendees
Ongoing

 

4. PROPOSAL COMPONENTS

 
Discussion

  • Components to be included:
ü  Problem statement, solutions
ü  Case Diagram
ü  Domain Model (UML)
ü  Mock user interface
ü  Sample input data
ü  Sample output data
ü  Implementation schedule

Action items
Person responsible
Deadline
  • Details and delegation of work will be discussed in next meeting
-
-