Kevin and I both have some concerns over David's commitment and willingness to take on the level of work required for this project.
To date, I feel I have done an overwhelming amount of the work we have accomplished. I wouldn't mind so much if I was beginning to get a feeling he has worked to understand the Revolution system, the Atmel MEGA1280, our requirements, or the software design. It often appears he hasn't even learned enough to ask the right questions and seems to want to minimize everything from the requirements to the design. "Let's just do it, it's so easy" is a sentiment I feel he has conveyed but then he doesn't show a clear enough undertsanding to just do it.
Maybe I have been more dominant and not as much of a team player as I should. I know I have tried to communicate the importance of studying and understanding the documentation we have available. I have tried to work over the functional and design requirements but then I'll get a comment or question which makes me wonder if he's done much reading at all.
Today, Kevin and I decided that I should talk to him. We expected meat on the bones of the design I provided for handling changes to the switches and sensors. This is really a pretty easy thing to do, especially since I had provided control flow and several algorithms, but again we don't have what we need. Kevin is preventing us from writing code until he is confident we understand enough to move forward. This can only be displayed through clear and concise design work. I will talk with David and work with him on Thursday. I will be direct on asking him if he has any questions and trying to ascertain how much he really understands. I'll lay out the expectations clearly. I think Kevin has done a pretty good job of this already but we want to make sure we haven't failed in our communications.
On Friday, 11-10-06, we need to have a solid design for the complete system. I've taken on the hardest part of the project in designing the serial IO and protocol modules. We are basically ready to go there. I understand the registers and bits that need to be manipulated to make the microcontroller do what I need it to do. There is a big learning curve here since there are many details hidden in the datasheet for control register requirements. The code needs to be written in a certain way and all bits must be at their proper setting to enable the microcontroller to perform as expected. It isn't as simple as just writing code. Kevin and I both hope we will see David step up to the plate.
Tuesday, November 07, 2006
Overall Comments
This project is much larger than it might appear. To begin with, we are dealing with a microcontroller instead of a full system. This is a totally foreign environment to many CS, and apparently CE, undergrads so the first hurdle is to understand the microcontroller, the different approaches to design and coding required, and what tools are available.
The second issue is our integration to a much larger project. We are developing software to control the Small Switch Panel component of the Revolution system. The other, and much larger, systems are the Control Unit and the Display Unit. In order to understand how our component integrates with the others we need to understand the requirements of the other components. A second version of the system does not include the Display Unit but has an expanded switch panel called the Large Switch Panel. We are not writing the code for the large switch panel but our code will be used as a basis for the later development of that component. We must always be aware of the overall system requirements and make sure we don't do anything that will restrict the later development required.
The third issue is the tools we will need to utilize. The Atmel microcontrollers can use several different cross-platform compilers and IDEs for software development. All of these were foreign to us at the onset of this project. Kevin has defined the Coding Conventions so we also need to become familiar with those. Kevin has also required we use Doxygen for our comments and eventual documentation and manuals. While Doxygen may be easy to jump in to there is still a big learning curve if we want to utilize it to the best of its capabilities.
There is a huge amount to do and every day must be used wisely.
The second issue is our integration to a much larger project. We are developing software to control the Small Switch Panel component of the Revolution system. The other, and much larger, systems are the Control Unit and the Display Unit. In order to understand how our component integrates with the others we need to understand the requirements of the other components. A second version of the system does not include the Display Unit but has an expanded switch panel called the Large Switch Panel. We are not writing the code for the large switch panel but our code will be used as a basis for the later development of that component. We must always be aware of the overall system requirements and make sure we don't do anything that will restrict the later development required.
The third issue is the tools we will need to utilize. The Atmel microcontrollers can use several different cross-platform compilers and IDEs for software development. All of these were foreign to us at the onset of this project. Kevin has defined the Coding Conventions so we also need to become familiar with those. Kevin has also required we use Doxygen for our comments and eventual documentation and manuals. While Doxygen may be easy to jump in to there is still a big learning curve if we want to utilize it to the best of its capabilities.
There is a huge amount to do and every day must be used wisely.
The Design Document
All through the requirements elicitation process I was mulling design ideas over in my head. I have scoured through the requirements for the other components of the Revolution system to understand exactly what our component needs to do and how it will integrate with the other components. I have also read most of the Atmel MEGA1280 microcontroller datasheet to understand the limitations and requirements of the environment we need to work in.
A few weeks ago I created a hand written version of the Control Flow required for the software running the small switch panel. I identified the needed functionality to meet our requirements and developed a few algorithms to handle the difficulties we faced working in a microcontroller environment, especially regarding timing and making sure we can blink lights at the correct rate and ensure a change has really occurred to any of the switches or sensors before responding to them. I developed a timing mechanism we can utilize for the entire system to handle all of our timing requirements and also developed the basic outline for handling all of the switch and sensor changes we need to respond to. I developed the data structures required for overall system functionality but admit these still need some refinement.
The most difficult part of this design is dealing with the limitations of the serial communication we have available in the Atmel MEGA1280 microcontroller. The serial port and USART only transmit or receive one character at a time. Kevin made it clear that all communications need to be non-blocking. It took me a little while but with Kevin's prodding and advice, research of other solutions that have been developed, studying the 1280 datasheet, and sheer determination I developed the design for the serial communication layer and the protocol layer of our network communications.
Last week, in order to make sure we had discussion material for our meeting with Kevin, I wrote the entire design document we have to date. It included Serial IO, Protocol, Main Loop, Switch, Light Sensor, Magneto Switch, and Reset modules. Last Friday I was aware, and Kevin reinforced that just thowing everything we needed down on paper was not enough and thr document needed refinement, the design needed better flexibility and detail, and we needed to be done by our meeting today.
David and I agreed that I would continue to work on the Serial IO and Protocol modules and he could take what I have developed (basic design and control flow) for the other components and refine the design.
Today, the Serial IO and Protocol modules are basically done. I have two minor changes to implement in the design and will have these done tomorrow. I will begin coding these modules and be ready to make sure everything else gets done so Vertical Power will meet its deadlines.
A few weeks ago I created a hand written version of the Control Flow required for the software running the small switch panel. I identified the needed functionality to meet our requirements and developed a few algorithms to handle the difficulties we faced working in a microcontroller environment, especially regarding timing and making sure we can blink lights at the correct rate and ensure a change has really occurred to any of the switches or sensors before responding to them. I developed a timing mechanism we can utilize for the entire system to handle all of our timing requirements and also developed the basic outline for handling all of the switch and sensor changes we need to respond to. I developed the data structures required for overall system functionality but admit these still need some refinement.
The most difficult part of this design is dealing with the limitations of the serial communication we have available in the Atmel MEGA1280 microcontroller. The serial port and USART only transmit or receive one character at a time. Kevin made it clear that all communications need to be non-blocking. It took me a little while but with Kevin's prodding and advice, research of other solutions that have been developed, studying the 1280 datasheet, and sheer determination I developed the design for the serial communication layer and the protocol layer of our network communications.
Last week, in order to make sure we had discussion material for our meeting with Kevin, I wrote the entire design document we have to date. It included Serial IO, Protocol, Main Loop, Switch, Light Sensor, Magneto Switch, and Reset modules. Last Friday I was aware, and Kevin reinforced that just thowing everything we needed down on paper was not enough and thr document needed refinement, the design needed better flexibility and detail, and we needed to be done by our meeting today.
David and I agreed that I would continue to work on the Serial IO and Protocol modules and he could take what I have developed (basic design and control flow) for the other components and refine the design.
Today, the Serial IO and Protocol modules are basically done. I have two minor changes to implement in the design and will have these done tomorrow. I will begin coding these modules and be ready to make sure everything else gets done so Vertical Power will meet its deadlines.
The ICD Document
The ICD is the Internal Communication Document. It contains the guidelines for network communications between the various components of the Revolution product. Kevin asked us to help him out with completing this document. Kevin had the format of a network packet defined and several of the command packets defined also. I scrubbed our requirements doc and the requirements docs Kevin had for the other components to develop a complete list of the communications required for the Revolution system.
My discussions with Kevin during this process refined our concept of how the network would need to behave and developed additional requirements.
Kevin provided the details for the kind of information I had identified we needed to transmit and I edited the final draft to incorporate his suggestions and details.
My discussions with Kevin during this process refined our concept of how the network would need to behave and developed additional requirements.
Kevin provided the details for the kind of information I had identified we needed to transmit and I edited the final draft to incorporate his suggestions and details.
The Requirements Document
The requirement elicitation process and the creation of our requirements document was somewhat of a team effort. David and I did hold brainstorming sessions down at Vertical Power, but he didn't quite grasp the level of detail we needed for the functional requirements and didn't seem to have studied the documents Kevin provided (marketing reqs and the CU functional reqs) enough to have a clear understandingof exactly what we needed to do. I developed probably 95% of the functional requirements and did all of the write up for that section of the document. David did contribute by creating the rest of the requirements document but I think we could have done a much better job following the examples in the book and the Volere template rather than the bare bones Vertical Power version we did use as a guideline.
In an attempt to try and get David more familiar with the functional reqs we would need to implement I suggested he develop the test procedures and requirements to prove out each of our functional requirements. He took on the assignment but both Kevin and I feel that portion of our project needs a bit more work.
In an attempt to try and get David more familiar with the functional reqs we would need to implement I suggested he develop the test procedures and requirements to prove out each of our functional requirements. He took on the assignment but both Kevin and I feel that portion of our project needs a bit more work.
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)