Project Learning Statements

 

General

I feel the project was quite beneficial to me in experiencing a rapid development plan from beginning to end. My personal experience was very rich because of the benefit of being on both groups and seeing two different group dynamics--both effective, but different.

The challenge of working together and learning from each other was very satisfying and rewarding, and I am very grateful for the class experience. 

I learned that I am lucky to be in this program with my classmates. No matter what time of day I had a problem, someone was always there to help. Many times, I got help from members of the other team. 

Luckily, our group is well balanced in terms of experience, personalities, and diversity. Accordingly, the atmosphere was conducive to learning, sharing, trust, and dependence. 

I am very proud of the effort this team has put forth throughout this semester. It is a good feeling to be able to point to a finished product and say, "Yeah. We did that!" 

 

Technical 

From a technical standpoint, I learned in leaps and bounds. …My PowerBuilder skills have tripled in terms of competence and efficiency and they are still increasing to this day. 

After spending 60 hours working on DB queries, I have a good understanding of SQL. There is no substitute for hands on learning for programming development. 

I've learned a heck of a lot of ERWin, SQL, PL/SQL, and Powerbuilder! I have had a ton of fun doing so and think that the format of this project has been very conducive to technical learning -- having a real client and real screwed up data to work with ... . 

Our group managed to divide up PL SQL code so EVERYONE was responsible for writing query procedures. I feel this was very effective, and I learned how to create cursors and why we need them. I also learned that it is necessary to document the code, so others know what it does. 

ERWin is now my friend. I have come to understand why RDBS are so popular and powerful. 

ERWin diagrams are fundamentally important to creating a workable PowerBuilder project. I learned that database design issues span an entire project. 

The data model changed quite a bit more than anticipated once we started writing the SQL queries. 

I have learned the most about Oracle and PB by working on the queries, developing some screens and reports myself and beta testing the entire PB application. I think it is very important that someone who thoroughly understands the Req. Analysis is involved in testing the final products. 

By writing Oracle functions on the server, we are giving McIntire a thin client system that should be easy to maintain and easily enhanced. Powerbuilder design was simplified by doing this. 

Using ForeHelp software to develop winhelp executable files. 

My 'try-and-error' ability is enhancing. 

More than anything else it has given me the confidence that I can pick up a new technology and learn reasonably quickly. 

 

Process 

My experience lies primarily in development and as such I find that I have been lacking experience encompassing the entire life cycle. The project allowed me to experience all phases of the life cycle and experiment with an iterative development approach which I believe was very successful.

I learned a tremendous amount about the benefits of planning and having a development model/framework that fits the task--such as the spiral method in our case. Although we did not use it exclusively, we learned about reviewing, mitigating, and monitoring risks all throughout the project. 

Fuzzy front end – I hate to waste that time, but many of my teammates did not feel the urgency.

The value of regular meetings and personal accountability was demonstrated. 

Requirements specification really took the most time! (RAD book is right on!). 

I think the one thing that made the largest impression on me was the fact that systems development is only about 15% actual construction. The other 85% is the processes of analysis, design, scheduling, risk management, and testing. 

We've learned that doing all that planning (requirements gathering, risk analysis, story-boarding, etc.) really does make life easier in the long run. I think this will become even more evident as the next two hectic weeks come to a closure. 

Identifying the classical mistakes. We did have some of these mistakes. 

Requirements certainly evolve somewhat during the life of a project. 

I love the risk management plan and process and would fight to have something similar on any project that had my participation. 

Client meetings must be carefully controlled and the group benefits if we meet for 5-10 minutes before and review the notes immediately afterwards to determine the To-Do Lists. 

I feel quite capable of managing a software development project when I leave this program. Managing the client, developing requirements, writing a proposal, managing meetings, sharing information, schedule management, and testing are among the process skills I developed. I now feel quite capable of choosing and implementing a methodology.

 

Interpersonal 

Class lectures/readings/discussions about the importance of the people dimension in software development project, combined with the situations presented in the group dynamics of the project, made learning intense and immediate. 

Early in the semester, some of the members would present ideas, then be very defensive when their ideas were questioned or challenged. The resulting discussions could be very heated. After a few weeks, it became apparent that the group would study, and if necessary, challenge an idea. As a result, team members were better in presenting and defending ideas. 

Communication: I learned that it is fundamentally important to communicate with all stakeholders (team members, clients & professors) so that all members are on the same page. E-mail is the greatest invention of our times! 

Our requirements changed significantly from our initial concept, and I feel that good communication with the client was key to our success. 

Personalities: It is important to understand that some people are not assertive, and may be left out of portions of the project because a lot of us move and speak quickly. We must try very hard to incorporate those who don't assert themselves when assigning tasks. 

Morale and Synergy: Teams that take time to build relationships work very well together. From the start, our group did the 'little things' to help each other. Now, people are willing to give the extra time (AKA voluntary overtime) to finish the project. 

I learned that there is no substitute for quality, supportive teammates. 

I have definitely expanded my technical knowledge base. This is mainly attributable to working side by side with people who are technically superior, but gracious enough to take the time to teach those who are eager to learn. 

I was surprised to find out how little I trust other people to do coding until they have proven themselves to me! 

Working in a team environment really made me ask myself, "How much of a team player am I?" I have had many experiences working with teams, but I will certainly take away the most lessons from working with this particular team. Lessons like:  

1. putting aside your own interests and aspirations in favor of those which will benefit the greater-good of the team.  

2. good people skills are absolute essentials for all members, especially coordinators and task managers.

It rehashed my belief that in the initial stages of any project, people should be put ahead of the technology and the process. The team should build trust and respect for each other. This earned trust and respect can be a great asset during crunch time or when things go wrong. 

The ideal size of a team is 4-5-members.

By breaking out into smaller groups for specific tasks, there weren’t any span of control problems. Ten people was a good number for a project of this scope. 

I think that six to seven group members could have completed the project.

 

Suggestions for Improvement