Journal Assignment #1 - Software Engineering

What I Think of the Software Engineering Process

Marty Ridens
CS460 - Fall 2006
University of New Mexico

I have had some experience in industry having worked as a semiconductor manufacturing engineer for almost 15 years. I was involved in two start-up plants where I was in charge of a large portion of the metrology equipment. In my last effort I negotiated several multi-million dollar deals and have quite a lot of experience on the customer and producer sides of the product development process. I had to specify the requirements for the equipment, perform evaluations of the tools developed by competing companies, create binding cost, delivery, and performance agreements, and present the results of my analysis at very high level meetings for approval by the president and upper management of the company. Internally, I had to create timelines for implementation of the delivered products, train engineers and production workers on the use of the equipment, set performance standards and testing procedures, and guarantee the tools met all specifications.

Now that I have embarked on a second career in computer science, I see the software engineering process as having many similarities to the kind of work I've done before. First and foremost, as product developers, we are part of a team. This team consists of the product designers and developers, the customer or client, the financier if different from the customer, and the end users. Each part of the team brings their expectations and requirements to the table and the software engineering process helps to resolve any differences, communicate exactly what is expected and what will be delivered, and ensure the resulting product fulfills as many of the customers requirements as is possible given budgetary and time constraints. If the developers cannot meet the customer's expectations then this should be flushed out in the early meetings where he still has time to find appropriate alternatives. Essential to this process is a clear understanding of the client's initial requirements and expectations. Changes will occur during the development process but the cost of these changes should be negotiated when they arise. At the onset, any risks should be clearly communicated and all potential failures to meet agreed upon deliverables should be understood.

What we are trying to do is engineer a software solution to a client's requirements within his budgetary and time constraints. Part of the problem is that he might not even have a clear understanding of what the solution is. Clear and frequent communication is the bedrock of this process. If the point of contact is a manager type then communication must be established with the end users to ensure the product will not be ignored or worked around. The delivered product must meet all the requirements of the customer but it must also be usable to those who will be working or playing with it.