http://vdubshouse.zapto.org/parallax/ - Look at the "Project" column. While I don't have anything in the SPIN library yet, I (or you) can add something easily enough.
I've been around for a while, at least long enough to see this kind of "process stuff" discussed and implemented every which way. I can't tell ya how many times in my work life I get dinged for not filing someone's idea of proper paperwork. I could probably be successful if the paperwork pushers would stop changing the rules.
And this is the most important point. This is not about paper work, this is the opposite. This is: "What do we do when we did it best".
What can we do with zero paperwork? Well, we at least have to have code. We at least have to say what we are trying to do, so we know when to stop coding. We at least have to have some kind of tests to show that it does what its supposed to. And we want to keep all the material someplace where we can find them when we need them; scatter over various posts in the forums has been shown to be not a good way to do it.
So the goal is as close to zero, without missing the important stuff. We just have to define "important stuff". This is attempting identify the stuff that comes before the coding standard, when we design and develop the code.
Just because it has not worked with this group yet does not mean can't work. Its always difficult to start when everyone is untrained. Like anything else in this life, we have to learn the rules and practice before we get good at it. Its that old dogs and new tricks thing, as always.
Circuitsoft's attempt at a Gold Standard Process has been going on for three weeks now.
We have seen:
- Some folks believe that the Gold Standard material on the parallaxsemiconductor website is sufficient, some do not.
- Some folks feel that parallax should control and perform the whole process, some feel much of this could be off loaded to the comunity.
Circuitsoft has a Gerrit repository set up.
- So far, one additional reviewer submitted comments, basically saying "don't do this."
By invitation, Braino is also contributing to this experiment, by applying process control to the software development cycle. This involves identifying the funcion the code is expectwed to perform, identifying a method to test if those functions are perfomred properly, and by doing so, provide a method to record all this, and measure objectively the degree to which the item does what its intended.
- So far, we have not been able to determine what the function is expected to do.
- Because of this, we have not determined how to check that the item performs its functions correctly.
- Some folks are interested to see what this "process control" turns out to be; other folks simply don't want to see it and appear to be bothered that it exists.
- From lonesock's post in 207, we see a typical development process. It assumes all activity is private until the final step. This is the usual way its done. This is the least efficient way, any errors found require undoing previous work, and redoing all the previous steps that lead to the issue. Also, it only detects bug after the fact, we have to wait fot them to appear before we can fix them, it allows all the remaining bugs to go undetected. If this is sufficient, go with it. Braino's contribution to this experiment is trying something else, if anyone wants to participate, all are welcome, but please do not actively block the experiment.
- To move forward, we need to establish what the function needs to do so we can check it doe it, we could try this directly through tests. What does serial have to do in order to work? This would be details on the pulses, when they are sent and not sent, how many, how often.
I'm just curious when does the API to the function under development get defined as to what services it will make public? You could have something as simple as tx_byte and rx_byte being the only public functions or something as involved as rx_wait_for_char(c) and all kinds of special formatting and message building.
When we define the interfaces. I usually prefer to figure out what its supposed to do first, that usually tell us what the interfaces need to look like.
I'm just curious when does the API to the function under development get defined as to what services it will make public? You could have something as simple as tx_byte and rx_byte being the only public functions or something as involved as rx_wait_for_char(c) and all kinds of special formatting and message building.
mindrobots, that's a very good question and something that has been kicked around in the past. I believe a defined implementation is the key to successful libraries/objects. In this example, the underlying concept is a stream. All libraries that are a "type of" stream should implement the same core methods. That concept is probably beyond the scope of this exercise though.
This process is kind of like watching paint dry or grass grow -- except slower. Maybe you could change this to an interative process, where you take a first pass through all the steps, and then refine it a few times until everybody's happy. It might progress more quickly that way.
If I understand correctly our first example here is a software implementation if a UART. A hardware gadget that the Prop does not have onboard.
Given the obvious speed requirements it should clearly be written in PASM.
Yes, I have done one in C but that's a pain and does not mesh with the following.
Given the generality of the requirement, "Prop has no UART we should provide a soft UART" then it should be written in a way that is usable from any language in the same way that a real hardware UART is.
As such it only needs to provide features of a hardware UART, see any data sheet from UART manufacturers, Intel, Motorola, whatever.
As such it's API, if we can call it that should be at a basic register/command level.
Things like streams or even HEX/decimal I/O are off the table at this level.
If I understand correctly our first example here is a software implementation if a UART. A hardware gadget that the Prop does not have onboard.
Given the obvious speed requirements it should clearly be written in PASM.
Yes, I have done one in C but that's a pain and does not mesh with the following.
Given the generality of the requirement, "Prop has no UART we should provide a soft UART" then it should be written in a way that is usable from any language in the same way that a real hardware UART is.
As such it only needs to provide features of a hardware UART, see any data sheet from UART manufacturers, Intel, Motorola, whatever.
As such it's API, if we can call it that should be at a basic register/command level.
Things like streams or even HEX/decimal I/O are off the table at this level.
I agree that we need a low level set of objects that behave very much like their hardware counterparts, ie. at a basic register/command level.
I also think this illustrates what I think is a misunderstanding of what is being discussed in this thread.
I think the intent of this thread is to come up with standards for a "Gold Standard" to be applied to a more general OBEX, for want of better words "Quality Control for the Obex".
The "Gold Standard Objects" like on the ParallaxSemiconductor would be for the basic software versions of UARTS/I2C/SPI, etc.
So maybe...Do we need a better definition of what this thread is about and maybe a name other than "Gold Standard"?
I think the ideas here are headed in a good direction, but the thought that it is in competition with the Parallax "Gold Standard" is causing fear uncertainty and doubt...
At the risk of being stoned...maybe this thread needs a mission statement...
This process is kind of like watching paint dry or grass grow -- except slower. Maybe you could change this to an interative process, where you take a first pass through all the steps, and then refine it a few times until everybody's happy. It might progress more quickly that way.
Either way, nothing happens until somebody does something. If nobody can say what we are doing, or how we can test it, we don't have anything to do.
Some folks say, "we have no requirements, therefore we violate no requirements, therefore we are bug free". If that's acceptable, that fine; but that is not this.
From my perspective, we are waiting for circuitsoft to select some references, so we know what to test to. This is where we started, and have not moved past.
If that is not possible, we can just indentify the functions the serial must perform to be serial. Like bit times, stop bits, parity bits, etc, and decide how we will determine if these are correct or not.
It doesn't have to be hard. It just has to happen.
I also think this illustrates what I think is a misunderstanding of what is being discussed in this thread.
I think the intent of this thread is to come up with standards for a "Gold Standard" to be applied to a more general OBEX, for want of better words "Quality Control for the Obex".
This is my fault. Circuitsoft was responding to the "do it instead of talking about it" request. I added the bit about quality. But I didn't want to send everyone running and screaming. "Quality control" is usually associated with "testing quality in" which cannot work, or "stopping bugs before they get out" which is too late. This process stuff is about "preventing bugs from happening in the first place" and is the most efficient, cost effective, and fastest method to date.
The braino part of the discussion is "measurement of the software development process". But, it needs a project to measure; as we see, just discussing the process itself doesn't provide a context for anything. We need to see it in action to know what we're talking about.
Yes, before we commence on a major thread like this we should have a clear objective in mind.
The objective, drawn up by a forum member should be reviewed by the thread review board prior to publication.
Following publication of the thread's requirements we can commence with the thread detailed design.
Thread detailed design will take into account such things as:
1) The intended audience of the thread.
2) The most appropriate language for the thread.
3) The most rigorous industry standard thread design practices should be followed.
With the thread detailed design in place, having been reviewed by the thread review board, we can commence with construction of the thread itself.
Each posting within the thread will of course be subject to review to be sure that it fulfills the original thread requirements. And a unit test of each post will be expected.
I look forward to working with you on this endeavor. I'm sure if we pull together in this process we can get a Gold Standard thread completed prior to the heat death of he universe.
At the risk of being stoned (as in virtual rocks being cast in my direction, not, well, not the other one)....
All I can say is stay tuned for a bit more, I may be come the target of outrageous slings and arrows with a new thread or two, or be commenting on my own threads due to a lack of interest.
This is my fault. Circuitsoft was responding to the "do it instead of talking about it" request. I added the bit about quality. But I didn't want to send everyone running and screaming. "Quality control" is usually associated with "testing quality in" which cannot work, or "stopping bugs before they get out" which is too late. This process stuff is about "preventing bugs from happening in the first place" and is the most efficient, cost effective, and fastest method to date.
The braino part of the discussion is "measurement of the software development process". But, it needs a project to measure; as we see, just discussing the process itself doesn't provide a context for anything. We need to see it in action to know what we're talking about.
Here I think describes where we seem to have two camps.
We have the "Control the Process" camp and the "Control the Deliverable" camp. I understand that the "Control the Process" camp will say that controlling the process is how we control the deliverable.
However, what we *need* in order to have nice solid objects is to "Control the Deliverable".
This would be things like documentation, testing, coding standards for items that are the deliverable.
In addition we *could* define best practice "Control the Process" guidelines that help achieve the desired deliverable.
I'm not demeaning what Braino is suggesting, I'm just saying he is defining a way to achieve the desired deliverable, but we also need to define what a desired deliverable looks like.
I want to see Braino's process worked through as I think it will be helpful in achieving high guality deliverables, both here and in my day to day consulting work.
I think "Control the Deliverable" has a couple of components:
1) The generic stuff that would apply regardless of underlying language: Specification Docs, Testing Docs, etc.
2) The specific stuff: coding standards based on language, etc.
So, I've set up Gerrit code review on my home server. You can access it at http://vdubshouse.zapto.org/parallax/. As a first change, I submitted a very basic README file and, like any other commits, would like comments/suggestions before fully committing it.
So, I'll do my best to watch this thread, but Gerrit has conversation threads associated with each change, so code discussions should happen there.
Thanks, everyone, and if you have any questions, please post them here.
Oh, and, should this gain traction, there should be little difficulty moving the entire thing into Parallax' hands.
To me this means that the mechanics of a review can proceed. We've verified that comments are possible.
So, the original mission statement of this thread has been fulfilled to the point that what the README (DEVEL.txt) says is possible.
I'll say that I have not attempted to use GIT with the site, because that was not important to me (that importance may change).
If you want to actually do a review, then there are other important factors that need to be well defined, otherwise IMHO it is a waste of time.
We tried to discuss other important factors here, but obviously that is OT.
I'm sorry if you're waiting on me to provide requirements. I've been poking around trying to find some, but I'm also hugely bogged down at work. I'll see if I can get to it tomorrow evening.
I'm sorry if you're waiting on me to provide requirements. I've been poking around trying to find some, but I'm also hugely bogged down at work. I'll see if I can get to it tomorrow evening.
A review of what has already been hashed out "at your convenience" would be nice.
Wood, Bronze, Silver, and Gold are good quality categories, and there should be minimum requirements for each level.
Do we need check boxes for such items?
This is my list (I've not left anything out on purpose). Stars could be check boxes.
Wood (OBEX level):
* Submitted for review
* Meets all other requirements as defined by the submitter
* Submitter gives status and goals of project if available
Bronze:
* Meets all Bronze and Wood requirements
* Has at minimum a demonstration program
* Has a description of purpose
* Has a description of user interface if necessary
* Has hardware setup instructions if necessary
* Evidence that demonstration program works for many users for intended purpose
* Meets all other requirements as defined by the Bronze Standards body
Silver:
* Meets all Silver and Bronze requirements
* Has a detailed Design Specification
* Has unit test procedures (tests of API functions)
* Meets the full coding standard for the language
* Standards include fully documented APIs
* Meets all other requirements as defined by the Silver Standards body
Gold:
* Meets all Gold and Silver requirements
* Evidence of meeting the Design Specification
* Has a full centrally accessible test harness and test cases (with code and/or hardware)
* Evidence of meeting all specified tests
* Evidence of meeting applicable Protocol or other module specific standards
* Meets all other requirements as defined by the Gold Standards body
If you want to actually do a review, then there are other important factors that need to be well defined, otherwise IMHO it is a waste of time.
We tried to discuss other important factors here, but obviously that is OT.
Sorry, review of what? I can't tell what any of the code is trying to do, or why its trying to do it.
What other important factors need to be defined, besides the requirements?
Post 230 has some good stuff, but has Design Specification at the end instead of the beginning (where it could do some good).
The use of the word "requirements" does not appear to include what the code is supposed to accomplish, which is really the main thing we are concerned with.
It mentions test harness. Test harness is meaningless unless we establish what we want to test, and how we expect to test it. THEN we can worry about whether or not automation is possible.
Don't load up with additional burden unless it is absolutely needed. At this point the only thing needed is "what is it supposed to do" and "how do we know if it does that".
Several people have suggested using levels, and what I have suggested a possible way to accommodate that.
Wood would not need a design document or anything else except what the user wants to provide. A goal for a user might be the bronze level.
I've generalized the requirements for each level with a separate bullet that basically says "whatever else that level standards body" sets. If you want to restate and reorder things in the different levels, you are more than welcome to do that.
I've agreed in principal with your Gold standard list already. Anything else?
What you are doing is great and worth doing, and necessary, but not as part of what I am trying here, just yet.
What I'm trying to do is take a single simple item from idea, to requirements, to tests, to code, to final evaluation. THEN we can decide if its gold or brown, and what constitutes gold or brown, based on the data we collect.
Your method would confuse the GATES with the evaluation. And we can't yet tell if the gates make sense, because we don't know what the process is yet.
By all means do what your doing, but please take care to keep it separate from this experiment until its proper time. It would only muddle both to mix them at this point.
C.W. has a handle on it (post #227) but its too early to bring the two together.
The idle line is brought to a logic one state prior to transmission/reception of a character.
A start bit (logic zero) is used to indicate the start of a frame.
The data is transmitted and received least significant bit first.
A stop bit (logic one) is used to indicate the end of a frame. A frame consists of a start bit, a character of eight or nine data bits, and a stop bit.
A break is defined as the transmission or reception of a low (logic zero) for at least one complete frame time (10 zeros for 8-bit format, 11 zeros for 9-bit).
Now the questions are:
* If we have the five items listed, is it enough to be "serial"? If you disagree, please say why.
* Can we test that each of these things happen? We make a test for each thing we can test for. The test must be pass/fail yes or no; no maybe or interpretation.
* Is any item too complex for a single test? Any item too complex for a single test to give full evaluation must be broken down into two or more simpler items, until each item can be passed by a pass/fail yes/no test as above.
We are now checking if the reference is sufficient by breaking the referenced items into testable functions. If the reference falls short of our needs, we want to know now. If the items cannot be tested we want to know now. If everything is fine, we should end up with a list of things that we can test.
As a result of this step, there should be at least five tests, probably many more than five. This is a simple project, so there might be only five, a more complex project decompose items a couple times and get lots and lots of little tests.
** This next part is getting ahead of ourselves, but some folks are impatient and need to know what's going to happen next, so here you go. Remember, we have not not broken our requirements into testable items yet.
After we DECIDE that each item can be tested, we lay out the tests. I.E. "To test the idle line being brought to logic one state, we will 1) use a volt meter on the pin in initial development. 2) use Hi and Low displayed on the terminal screen during test. 3) use an LED on a bread board 4)..." or whatever we decide as appropriate. The idea is that is somebody has to come back in a year take over, they have enough to get started on our same path.
As soon as we decide an items is testable, we can start in on figuring out the actual test. BE aware that as we unravel the remaining items, they may impact our idea of the items we've already looked at, and we may have to go back an revisit "completed" items to check for changes.
Also, as soon as we decide we have a test for an item, we can start writing code that will pass the test. As above, if something makes us go back and change an existing test, we may also have to go back and change existing code.
To test them individually will require an oscilloscope, but I think the block as a whole can be tested by attempting serial passthrough with an FTDI chip.
To test them individually will require an oscilloscope, but I think the block as a whole can be tested by attempting serial passthrough with an FTDI chip.
I was thinking test with a volt meter first, test with oscilloscope at integration, and test with a software function after. What ever is simplest.
In my case I don't have viewport set up. I don't like adding extra hardware or software if it can be avoided. Of course each can do whatever is convenient, my aim is to enable the most people,so less additions is favored
Edit - if multiple folks are doing the tests, we should have at least one method that everyone can use to reproduce each others results, but other specialized methods are fine as them might give additional information. We just won't expect all members to perform tests with the equipment to don't have.
Comments
And this is the most important point. This is not about paper work, this is the opposite. This is: "What do we do when we did it best".
What can we do with zero paperwork? Well, we at least have to have code. We at least have to say what we are trying to do, so we know when to stop coding. We at least have to have some kind of tests to show that it does what its supposed to. And we want to keep all the material someplace where we can find them when we need them; scatter over various posts in the forums has been shown to be not a good way to do it.
So the goal is as close to zero, without missing the important stuff. We just have to define "important stuff". This is attempting identify the stuff that comes before the coding standard, when we design and develop the code.
Form.
History? The more people who (say they) use it, the more glitter?
It doesn't work from a forum format. true.
Just because it has not worked with this group yet does not mean can't work. Its always difficult to start when everyone is untrained. Like anything else in this life, we have to learn the rules and practice before we get good at it. Its that old dogs and new tricks thing, as always.
Circuitsoft's attempt at a Gold Standard Process has been going on for three weeks now.
We have seen:
- Some folks believe that the Gold Standard material on the parallaxsemiconductor website is sufficient, some do not.
- Some folks feel that parallax should control and perform the whole process, some feel much of this could be off loaded to the comunity.
Circuitsoft has a Gerrit repository set up.
- So far, one additional reviewer submitted comments, basically saying "don't do this."
By invitation, Braino is also contributing to this experiment, by applying process control to the software development cycle. This involves identifying the funcion the code is expectwed to perform, identifying a method to test if those functions are perfomred properly, and by doing so, provide a method to record all this, and measure objectively the degree to which the item does what its intended.
- So far, we have not been able to determine what the function is expected to do.
- Because of this, we have not determined how to check that the item performs its functions correctly.
- Some folks are interested to see what this "process control" turns out to be; other folks simply don't want to see it and appear to be bothered that it exists.
- From lonesock's post in 207, we see a typical development process. It assumes all activity is private until the final step. This is the usual way its done. This is the least efficient way, any errors found require undoing previous work, and redoing all the previous steps that lead to the issue. Also, it only detects bug after the fact, we have to wait fot them to appear before we can fix them, it allows all the remaining bugs to go undetected. If this is sufficient, go with it. Braino's contribution to this experiment is trying something else, if anyone wants to participate, all are welcome, but please do not actively block the experiment.
- To move forward, we need to establish what the function needs to do so we can check it doe it, we could try this directly through tests. What does serial have to do in order to work? This would be details on the pulses, when they are sent and not sent, how many, how often.
When we define the interfaces. I usually prefer to figure out what its supposed to do first, that usually tell us what the interfaces need to look like.
"...like watching paint dry..." that would be quite pleasant. I was already thinking in terms of Bamboo torture http://en.wikipedia.org/wiki/Bamboo_torture
I just can't help watching...
If I understand correctly our first example here is a software implementation if a UART. A hardware gadget that the Prop does not have onboard.
Given the obvious speed requirements it should clearly be written in PASM.
Yes, I have done one in C but that's a pain and does not mesh with the following.
Given the generality of the requirement, "Prop has no UART we should provide a soft UART" then it should be written in a way that is usable from any language in the same way that a real hardware UART is.
As such it only needs to provide features of a hardware UART, see any data sheet from UART manufacturers, Intel, Motorola, whatever.
As such it's API, if we can call it that should be at a basic register/command level.
Things like streams or even HEX/decimal I/O are off the table at this level.
I agree that we need a low level set of objects that behave very much like their hardware counterparts, ie. at a basic register/command level.
I also think this illustrates what I think is a misunderstanding of what is being discussed in this thread.
I think the intent of this thread is to come up with standards for a "Gold Standard" to be applied to a more general OBEX, for want of better words "Quality Control for the Obex".
The "Gold Standard Objects" like on the ParallaxSemiconductor would be for the basic software versions of UARTS/I2C/SPI, etc.
So maybe...Do we need a better definition of what this thread is about and maybe a name other than "Gold Standard"?
I think the ideas here are headed in a good direction, but the thought that it is in competition with the Parallax "Gold Standard" is causing fear uncertainty and doubt...
At the risk of being stoned...maybe this thread needs a mission statement...
C.W.
Either way, nothing happens until somebody does something. If nobody can say what we are doing, or how we can test it, we don't have anything to do.
Some folks say, "we have no requirements, therefore we violate no requirements, therefore we are bug free". If that's acceptable, that fine; but that is not this.
From my perspective, we are waiting for circuitsoft to select some references, so we know what to test to. This is where we started, and have not moved past.
If that is not possible, we can just indentify the functions the serial must perform to be serial. Like bit times, stop bits, parity bits, etc, and decide how we will determine if these are correct or not.
It doesn't have to be hard. It just has to happen.
This is my fault. Circuitsoft was responding to the "do it instead of talking about it" request. I added the bit about quality. But I didn't want to send everyone running and screaming. "Quality control" is usually associated with "testing quality in" which cannot work, or "stopping bugs before they get out" which is too late. This process stuff is about "preventing bugs from happening in the first place" and is the most efficient, cost effective, and fastest method to date.
The braino part of the discussion is "measurement of the software development process". But, it needs a project to measure; as we see, just discussing the process itself doesn't provide a context for anything. We need to see it in action to know what we're talking about.
Yes, before we commence on a major thread like this we should have a clear objective in mind.
The objective, drawn up by a forum member should be reviewed by the thread review board prior to publication.
Following publication of the thread's requirements we can commence with the thread detailed design.
Thread detailed design will take into account such things as:
1) The intended audience of the thread.
2) The most appropriate language for the thread.
3) The most rigorous industry standard thread design practices should be followed.
With the thread detailed design in place, having been reviewed by the thread review board, we can commence with construction of the thread itself.
Each posting within the thread will of course be subject to review to be sure that it fulfills the original thread requirements. And a unit test of each post will be expected.
I look forward to working with you on this endeavor. I'm sure if we pull together in this process we can get a Gold Standard thread completed prior to the heat death of he universe.
At the risk of being stoned (as in virtual rocks being cast in my direction, not, well, not the other one)....
All I can say is stay tuned for a bit more, I may be come the target of outrageous slings and arrows with a new thread or two, or be commenting on my own threads due to a lack of interest.
Here I think describes where we seem to have two camps.
We have the "Control the Process" camp and the "Control the Deliverable" camp. I understand that the "Control the Process" camp will say that controlling the process is how we control the deliverable.
However, what we *need* in order to have nice solid objects is to "Control the Deliverable".
This would be things like documentation, testing, coding standards for items that are the deliverable.
In addition we *could* define best practice "Control the Process" guidelines that help achieve the desired deliverable.
I'm not demeaning what Braino is suggesting, I'm just saying he is defining a way to achieve the desired deliverable, but we also need to define what a desired deliverable looks like.
I want to see Braino's process worked through as I think it will be helpful in achieving high guality deliverables, both here and in my day to day consulting work.
I think "Control the Deliverable" has a couple of components:
1) The generic stuff that would apply regardless of underlying language: Specification Docs, Testing Docs, etc.
2) The specific stuff: coding standards based on language, etc.
C.W.
To me this means that the mechanics of a review can proceed. We've verified that comments are possible.
So, the original mission statement of this thread has been fulfilled to the point that what the README (DEVEL.txt) says is possible.
I'll say that I have not attempted to use GIT with the site, because that was not important to me (that importance may change).
If you want to actually do a review, then there are other important factors that need to be well defined, otherwise IMHO it is a waste of time.
We tried to discuss other important factors here, but obviously that is OT.
Anyone up for a fresh start?
A review of what has already been hashed out "at your convenience" would be nice.
Wood, Bronze, Silver, and Gold are good quality categories, and there should be minimum requirements for each level.
Do we need check boxes for such items?
This is my list (I've not left anything out on purpose). Stars could be check boxes.
Wood (OBEX level):
* Submitted for review
* Meets all other requirements as defined by the submitter
* Submitter gives status and goals of project if available
Bronze:
* Meets all Bronze and Wood requirements
* Has at minimum a demonstration program
* Has a description of purpose
* Has a description of user interface if necessary
* Has hardware setup instructions if necessary
* Evidence that demonstration program works for many users for intended purpose
* Meets all other requirements as defined by the Bronze Standards body
Silver:
* Meets all Silver and Bronze requirements
* Has a detailed Design Specification
* Has unit test procedures (tests of API functions)
* Meets the full coding standard for the language
* Standards include fully documented APIs
* Meets all other requirements as defined by the Silver Standards body
Gold:
* Meets all Gold and Silver requirements
* Evidence of meeting the Design Specification
* Has a full centrally accessible test harness and test cases (with code and/or hardware)
* Evidence of meeting all specified tests
* Evidence of meeting applicable Protocol or other module specific standards
* Meets all other requirements as defined by the Gold Standards body
Sorry, review of what? I can't tell what any of the code is trying to do, or why its trying to do it.
What other important factors need to be defined, besides the requirements?
Post 230 has some good stuff, but has Design Specification at the end instead of the beginning (where it could do some good).
The use of the word "requirements" does not appear to include what the code is supposed to accomplish, which is really the main thing we are concerned with.
It mentions test harness. Test harness is meaningless unless we establish what we want to test, and how we expect to test it. THEN we can worry about whether or not automation is possible.
Don't load up with additional burden unless it is absolutely needed. At this point the only thing needed is "what is it supposed to do" and "how do we know if it does that".
Several people have suggested using levels, and what I have suggested a possible way to accommodate that.
Wood would not need a design document or anything else except what the user wants to provide. A goal for a user might be the bronze level.
I've generalized the requirements for each level with a separate bullet that basically says "whatever else that level standards body" sets. If you want to restate and reorder things in the different levels, you are more than welcome to do that.
I've agreed in principal with your Gold standard list already. Anything else?
--Steve
What you are doing is great and worth doing, and necessary, but not as part of what I am trying here, just yet.
What I'm trying to do is take a single simple item from idea, to requirements, to tests, to code, to final evaluation. THEN we can decide if its gold or brown, and what constitutes gold or brown, based on the data we collect.
Your method would confuse the GATES with the evaluation. And we can't yet tell if the gates make sense, because we don't know what the process is yet.
By all means do what your doing, but please take care to keep it separate from this experiment until its proper time. It would only muddle both to mix them at this point.
C.W. has a handle on it (post #227) but its too early to bring the two together.
OK, I see the changes in gerrit, this looks very good.
I added a comment, the detail for that are in this post. I don't know how gerrit handles the "discussion" part.
For all folks watching, the first step is to decide what we are testing against.
We talked about what we are doing, got some suggestions, and now the author has selected a reference for serial
We see ffds1.h has additions, the remaining files are unchanged.
Please note, there also needs to be a reference for the prop data sheet for any prop project.
This is the reference sited for serial.
http://cache.freescale.com/files/microcontrollers/doc/data_sheet/MC68HC05B6.pdf
Page 6-5 is cited:
The idle line is brought to a logic one state prior to transmission/reception of a character.
A start bit (logic zero) is used to indicate the start of a frame.
The data is transmitted and received least significant bit first.
A stop bit (logic one) is used to indicate the end of a frame. A frame consists of a start bit, a character of eight or nine data bits, and a stop bit.
A break is defined as the transmission or reception of a low (logic zero) for at least one complete frame time (10 zeros for 8-bit format, 11 zeros for 9-bit).
Now the questions are:
* If we have the five items listed, is it enough to be "serial"? If you disagree, please say why.
* Can we test that each of these things happen? We make a test for each thing we can test for. The test must be pass/fail yes or no; no maybe or interpretation.
* Is any item too complex for a single test? Any item too complex for a single test to give full evaluation must be broken down into two or more simpler items, until each item can be passed by a pass/fail yes/no test as above.
We are now checking if the reference is sufficient by breaking the referenced items into testable functions. If the reference falls short of our needs, we want to know now. If the items cannot be tested we want to know now. If everything is fine, we should end up with a list of things that we can test.
As a result of this step, there should be at least five tests, probably many more than five. This is a simple project, so there might be only five, a more complex project decompose items a couple times and get lots and lots of little tests.
** This next part is getting ahead of ourselves, but some folks are impatient and need to know what's going to happen next, so here you go. Remember, we have not not broken our requirements into testable items yet.
After we DECIDE that each item can be tested, we lay out the tests. I.E. "To test the idle line being brought to logic one state, we will 1) use a volt meter on the pin in initial development. 2) use Hi and Low displayed on the terminal screen during test. 3) use an LED on a bread board 4)..." or whatever we decide as appropriate. The idea is that is somebody has to come back in a year take over, they have enough to get started on our same path.
As soon as we decide an items is testable, we can start in on figuring out the actual test. BE aware that as we unravel the remaining items, they may impact our idea of the items we've already looked at, and we may have to go back an revisit "completed" items to check for changes.
Also, as soon as we decide we have a test for an item, we can start writing code that will pass the test. As above, if something makes us go back and change an existing test, we may also have to go back and change existing code.
Would Hanno's Viewport be a good for testing?
C.W.
In my case I don't have viewport set up. I don't like adding extra hardware or software if it can be avoided. Of course each can do whatever is convenient, my aim is to enable the most people,so less additions is favored
Edit - if multiple folks are doing the tests, we should have at least one method that everyone can use to reproduce each others results, but other specialized methods are fine as them might give additional information. We just won't expect all members to perform tests with the equipment to don't have.