Thursday, October 05, 2006
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.
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.
Subscribe to:
Posts (Atom)