Rationale Notes

I will use this post to organize and record the thoughts and rationale for development and design decisions made during the software development for the Small Switch Panel portion of Vertical Power's Revolution product.

Journal Assignment #3 - Plan and Process

David and I have a different situation than most groups. We are part of a larger software development process which already has deadlines defined. Our motivation does not have to come from ourselves. We are driven by a desire to satisfy our customer (Vertical Power) and ensure that we are not the weak link in the chain. The company we are working for has real potential to make money and several people have devoted this portion of their professional lives to see their product come to fruition. When a student works on a project for a grade it is easy to make decisions to weaken the software development process, let deadlines slip, and do the minimal amount of work necessary to get whatever grade is desired. Being part of this Vertical Power team means that people are depending on us to make a high quality product. There are financial and professional repurcussions for the rest of the team if we do not do our job correctly so our motivation must come from a strong work ethic and sense of responsibility.

We are developing a system that must integrate smoothly with the product concept already developed by Vertical Power. Part of our requirement solicitation process is to ensure that our code will integrate with the overall system. Working through this process we have already uncovered several areas where the requirements for other components needed to be more clearly defined or did not cover boundary cases well enough. We are developing our requirements in conjunction with the requirement development process for the rest of the product and in so doing we are uncovering and resolving integration issues now instead of working in isolation and finding out the components don't play well together when it's really too late.

To be honest, David and I have not talked over what strategy we will use to develop our product yet. We have been swamped with understanding the function of our component within the system, defining detailed requirements, and making sure everything will integrate smoothly. The fact that our group only has two people in it is going to make a lot of things easier. We have already committed to two meetings a week with Vertical Power. We have had several working sessions where David and I worked closely together. We are spending time down at Vertical Power working together where any questions that arise can be immediately resolved by talking the issue over with Kevin. Communicaton, communication, communicationis where many software developers fail. The methodology we are pursuing will continue through the design, implementation, and testing processes.

We have not been following the "Waterfall Process", and I don't think anyone really ever does, because as the system requirements are being developed it is impossible, as a programmer, to not be thinking about design and implementation. Too many people skip the design part and think only about implementation when they see a requirement but that is a recipe for failure. We need to look at the big picture first, make sure it makes sense and will probably work, and then move to the fine details of implementation. I believe in top down design and bottom up coding. Creating extremely detailed requirements will facilitate the bottom up coding and unit testing processes while understanding the rationale for the detailed requirements and why they exist will facilitate the top down design and integration testing processes.

Our group is hampered in following any iterative process because our system will be designed to control a microprocessor on a board that doesn't exist yet. We do not have, and many people will smirk at this, the luxury of several beta releases with user testing followed by an eventual alpha release. The timeline for this product requires that we utilize extensive unit testing and integration testing measures to ensure the success of this development. It will be imperative that when the hardware is ready the software will work, and if it doesn't we'll have the test procedures defined to determine where the problem exists. The only way this will happen is by taking the requirements, design, coding, and testing components of this development to the nth degree. We need to follow a process which doesn't really exist yet called "get it right the first time". Everyone knows this is an impossible goal but we need to do our utmost to make it a reality.

The way we will achieve this goal is through top down design and bottom up coding and the requirements this philosophy imposes on the development process.

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.