This is a report of the experience of a student taking a co-operative work experience

course. I put it here because it so clearly points out the reasons for the various

techniques and methods we teach in software engineering. I have made some minor

modifications ( flagged as ???) to the report to protect the privacy of the student. The

spelling and grammar are those of the student.

Introduction

I am currently working at ??? located in ???. ??? was officially started in June of ???. I joined the company in June of 1997. The focus of the company is the development of software for ???. Our current projects are centered around the operations of ???. Current staffing is 11 full time and 2 part time employees. The development team consists of 4 developers, of which I am one.

Work Experience

The last four months have seen very radical changes in organization and emphasis of the company. Various factors have played into these changes. Specifically, I have learned that being a good programmer does not provide all that is needed for a successful project.

We are just concluding a project that was scheduled to take 1 year and has taken 2 years to complete and still has limitations that where not planned for. The company has had many post project reviews to determine what went right and specifically what went wrong. The three most fundamental aspects of our short comings were inadequate communication, not having a formal process of developing the software, and not understanding our client.

I have come to the realization that regardless of your programming ability, communication can often out way your abilities as a programmer. As a small startup company, we were in charge of extracting requirements, doing the design, and performing coding functions. With such a small organization we also were regularly left alone to manage our own time and prioritize our task. Countless hours were spent over at the ??? offices discussing requirements and learning the daily operations. Numerous documents where created and posters where made to reflect the requirements gathered, work flows, and the overall software design. Toward the end of the project it was determined that our communication did not properly convey our intentions nor the workflow of the newly designed system. Good communication was something that we underestimated and did not pay enough detail to. Milestones where often missed due to rework that had to be done because of misunderstanding between ourselves and the client. It appeared that we had a clear understanding of each other on paper, but in reality we were confusing many minor issues.

Software development is not an exact science. There is no formal method to developing software. Many programers feel that it is truly an art form. Software development processes have been introduced to provide a well defined and formal procedure that developers can follow to insure that projects are successful. We, initially, felt that many of the development processes where to controlling and did not directly apply to the project at hand. We did not want to be restricted. We felt that we had some good technology and that would carry the project. We later found that technology alone is not enough. Easy of Use, performance, and technology all play a factor.

By not having a known method for extracting requirements and recording them, we fumbled through various attempts to do such. One method would be tried that then was realized to be inadequate. Another method was then tied, only to have it not work quite the way we had intended. Every attempt got us closer to the desired result but our schedule was not geared to handle the extent that we had to take to finally extract the requirements for the system.

The management of the project was also an important task that was not realized. We had no single person in charge. Since we were small, the tasks were delegated to whomever was free and available to perform the task, whether this was attending meetings with the clients, gather requirements, or formalizing testing procedures. Many important bits of information fell through the cracks. Assumptions were made that someone else was taking care of things. Since no particular roles were assigned to anyone, may of that tasks were never addressed nor completely followed through from start to finish.

Computer Science is a rare major. Once you have your degree you have learned enough to do nothing. I have worked at various companies. They consisted of ???. I knew very little about these businesses. I knew how to do linked lists, hash tables, write compilers, render 3-D images, etc. For the ??? project, I was to automate the ??? office. I quickly learned what information they recorded and what format it was stored but I did not take enough time to understand what an assessor did or how they worked. I provided applications to help automate their operations but it did not always directly work well for them. Technically, it was good software but it could be seen how the software behaved that I did not understand the role of the assessor. The remaining months were spent better understanding their role and adapting the software accordingly.

Conclusion

In the last month at ???, significant changes have been made to better prepare us for the future. Management changes where made to ensure that someone is responsible for all tasks. Each person on the team has responsibilities and also a reporting/status mechanism has been put into place for providing accountability of all people and tasks.

Countless hours have been devoted to researching and developing a formal software development process that is adequate for our needs and one that we all understand and can work with. In picking a process, communication was the most important aspect. The process had helped us prioritize tasks, realize what project goals are, formal method of recording requirements, and providing a means to properly covey our efforts to the client.

A new appreciation for the client has been emphasized before any project is started. The following question is always asked: "Do you know your client well enough that you could take over their job?" If we cannot answer this question then more research is required and more time with the client is conducted. Until we have this in-depth understanding of our client, we do not want to start designing or coding the system.

I feel that over the last four months I have greatly broadened my view of what software development entails. It is not just being a good programmer. It involves communicating, organizing, following procedures, etc. The most important lesson I have learned is to always re-evaluate your current state and determine what needs to change and what you need to keep to better yourself and the project.