I should clarify; in fly-by-wire, you still have all the hydraulics of course. The computer has to move the actual flight surfaces somehow, and it isn't going to do it with a function call alone.:)
A typical small aircraft has mechanical linkages between flight controls and flight surfaces. So, when I push forward on the stick, the stick pulls on a linkage, which pulls on a long metal rod (or possibly a cable), which pulls on another linkage, which moves the elevator (the flight surface which controls pitch).
Your typical old-school big-jet (like a 737 for example) uses a hydraulic system. When I push on the yoke, the yoke pulls a linkage, which pulls a rod or a cable, which moves another linkage, which move valves which control hydraulic pumps, which in turn move the flight surfaces. Hydraulics are used in big planes, because the forces required to move the flight surfaces would exceed what a human is capable of.
"Fly By Wire" is where I move a stick or a yoke, and it activates a switch or rotates a potentiometer, which sends a signal off into a computer, which then moves the appropriate flight surface.
There are no mechanical linkages between the flght controls and the flight surfaces in, say, an Airbus A320. So in the strictest sense, there is no "manual backup". There is a "manual control", wherein you cut the computer out of the decision making process, so the plane does exactly what you tell it to, rather than what it thinks you want to do based on your input (the closest analogy I can think of would be disabling traction control in your car, but that's a pretty poor analogy. See my other post in this thread for more information on the A320's flight computers).
From a pure "flight control" perspective, cutting the computers and autopilot and whatnot out of the loop, fly-by-wire is likely the most reliable of all methods, since you cut out a lot of mechanical linkages and pullies and other physical stuff (which will eventually fail, no matter what, it's all a question of mean-time-between failures), and replace them mostly with solid-state electronics, which have extremely low failure rates, and extremely long MTBFs.
Fly-by-wire also makes it much easier for you to build a computer which controls the plane, since all your flight surfaces are already "digitally controlled".
I've flown a class D Airbus A320 simulator before (and by flown, I mean as the pilot). Class D sims are so realistic, that most airlines will let pilots log time in the sim as time in the air.
A child of four could fly that plane.
Essentially, a good way to think about it is; the plane is always on autopilot, and if you take "manual control" you're feeding requests into the autopilot, which it may or may not honor.
For example; pull back on the stick and set the throttle to minimum. The plane will start to pitch up, and your airspeed drops off. Once you get close to stall speed, the plane will start increasing throttle to maintain speed. Once it runs out of throttle, it will start decreasing the angle of attack. Even if you give it hard over rudder, the plane simply will not stall.
I did a "flame-out" landing, with no fuel, Gimli-Glider style, and aside from the fact that I blew out some tires (no ABS when the engines are out on an A-320), I landed the plane no problem.
My cousin, who used to fly for Air Canada, said that by Air Canada rules, they had to fly under pilot control on takeoff until they were at 500 feet. After that, they could let the computer fly the plane to their destination AND LAND without further human intervention.
As far as concerns over "computer faults" go; the Airbus computer consists of (IIRC) 7 processors, which all vote to determine what to do. If a given processor disagrees or starts acting wonky, it gets rebooted. Each of these 7 processors is running different code, based on different designs, by different teams of software engineers. The only thing they have in common is that they were developed from the same requirements.
This is kind of like saying "I need to continue to grow my per day spending. I need to find new and more plentiful ways to make money. Having lots of money has change my life, where I live, etc... I'm not sure I can afford a yacht any time soon, but If could, wouldn't that be cool?"
It's true; spending energy is fun and has many positive benefits, but at the moment our primary energy source is oil, and it isn't renewable. One day, maybe we'll have some new, safe, and more plentiful energy "income" sources, but right now we don't. When you're out of work, spending all your cash reserves is a dumb thing to do, and that's what we're doing with oil, right now. There's no "energy Visa company" we can borrow from while we're out of oil and waiting for fusion or high-altitude wind generation, either.
It is, in fact, even worse than the cash analogy; development of new energy technologies requires energy. If we let our energy reserves drop low enough, eventually we won't have the resources required to invest in new energy technology. It's like driving down the highway, and being close to empty. It's nice that there's a gas station 40 miles up the road, but if you keep the pedal to the metal, and burn up all your gas in 20 miles, you're still fscked.
Since you can't feel the keys, you have to be looking at the keyboard to use it. The last time I had to type on such a keyboard, with no "tactile feedback", was on an old Timex Sinclair 1000.
Well, aside from the fact that whenever I try to search or search and replace, it crashes. Anjuta looks very promising, but it doesn't seem very stable. I'm eagerly awaiting the 2.0 release.
All you need is the ability to trap all the energy from both stars. Some kind of container whose inside is it's outside. I predict this will give rise to a whole new industry in Dyson-Klein Bottles.
If you're into the tile based games, Zombies is kind of interesting, although IMHO it's a little overly random, and not nearly as interesting as the other games you listed. Still, it's fun.
A game we've been playing lately is Filty Rich, a "3D" board game by Richard Garfield (creator of, amongst other things, Magic: The Gathering). The idea is you open shops, and then collect income from them, with the objective being to be the first one to buy three luxuries (trophy spouse, patent of nobility, private jet, etc...). The "game board" is a binder with four 3x3 plastic card-protector sheets inside. When you open a shop you place it's "sign" into the card-pockets on the sheet (a sign could span multiple pockets), then you roll some dice to see which pockets get visited, and collect income, and then there's a 50% chance you'll move to a new random page.
The game is "3d" since on a given page you can "see through" to pages underneath. It's quite a clever and fun little game. You can see the rule-book at the link above, if you're curious.
So what metrics do you use? Do you just tell your team to get their defect/kloc down, without giving them any kind of plan or direction as to how?
The fact of the matter is, if you have a process, and you follow it on two different projects, you'll get two products of very similar quality at the end. If you don't follow a process, you'll get two products of random quality at the end.
CMM 1 you get for free. CMM 2 gives you guidelines as to how to establish a process, so you'll be "repeatable". CMM 3 gives you guidelines as to how to make your process better. When you get up into CMM 5, you have a process that makes itself better.
Again, you have to implement the "intent" of CMM, not the "letter". You don't want to measure your team against CMM, you want to use CMM to reduce your defects/kloc and your effort/kloc.
Come on, one of the cornerstones of our culture is "Mistrust authority, promote decentralisation". It really hurts to see authoritarian systems being promoted like that.
When you start talking about open source, I'd agree. But, when you talk open source, you're talking about a whole different beast. Most OSS projects have no Quality Assurance to speak of, other than the discipline applied by the developer to his own work. There are a lot of different discussions about why OSS succeeds, despite doing most of the things that classical engineering would shun, but regardless of which arguments you buy or don't buy, two things are obvious; OSS works, and the bazaar is nothing like the cathedral.
Once you start talking about the cathedral, you're no longer talking about our culutre, you're talking business. At the end of the day, I'd rather get my for-work projects done before the deadline with a minimum of fuss, so I can go home and work on more interesting projects. In order to do that, though, I need to the cooperation of the people around me, many of whom are not uber-hackers like you and me, but people who got into computers because that's where the money is, even though they'd really rather be doing something else.
The cathedral requires a common process which everyone must follow, otherwise we end up working late, past deadline, over-budget, and eventually go under.
Re:Capability Maturity Model
on
QA != Testing
·
· Score: 2, Interesting
This is an interesting argument, and it's one I hear a lot here, but let me ask you something;
What was your improvement in productivity, and how was it measured? What was the reduction in your (delivered defects):(effort expended) ratio? What was the reduction in your (lines of code delivered):(effort) ratio? One or both of these ratios have to go down.
If you don't have these numbers, you can't really say you've improved productivity, especially with a process like Scrum. Scrum makes it very easy to think you're more productive, because it gives you results every 30 days (in fact, to a lesser degree, every single day with your Scrum meeting). But are you actually more productive? There's a fair rework cost incurred by Scrum, due to the constant introduction of new requirements, which Scrum hides very well.
I don't have these numbers either, and I'm not sure if anyone has done such a study (although I've encouraged the group here that's pushing Scrum to measure them), so I can't say for sure which process is "better" from this perspective.
I will agree that Scrum does an excellent job of making developers feel good, which is one of their stated aims, but unfortunately, software exists not to please its developers, but to please its users.
Re:Capability Maturity Model
on
QA != Testing
·
· Score: 1
Or, there's something wrong with the certification. Or, the company lies to get certified.
I've worked in a few ISO 9001 certified shops which really didn't come close to ISO 9001.
Re:Capability Maturity Model
on
QA != Testing
·
· Score: 0, Offtopic
Why? Would you expect the head of process quality of Ford to be able to spin off perfect HTML? And if so, why? It's not even related to his job.
Believe me, I've encouraged him to redo his site, but he wrote it using some MS product, which generates IE-only HTML (likely a requirement of any MS software:) and he hasn't had time to rework it.
I'm not calling Scrum bizzare. Scrum seems like a good way to develop a piece of software where the requirements churn is very high. I have a hard time thinking of such a system off the top of my head. It might be an acceptable way to develop a low-churn system where you want your time-to-market to be next to zero, provided the cost of a failure is very low, and redeployment costs are minimal, and you don't mind burning some cash down the road to get to market first. A web-based email system, for example, might be a good candidate for scrum. I'd also think that you would need a fairly small team size for scrum to work properly, although I don't have data to back that up.
A mission critical system, though, where the cost of failure is high (say, death), is not really a good candidate for Scrum. If you worked at Boeing and found "777 left wing" in your process backlog, you'd probably want to seek employment elsewhere.
With any mission critical system, you need a very clear understanding of the requirements before you start design - otherwise there is a high probability that your design will fail to meet one of those requirements, and therefore the system will likely fail. The whole point of scrum is that you basically make up features (and, therefore, requirements) as you go along, and hack them in. Your product backlog is basically just a list of features you want but haven't had time to hack at yet.
The requirements of a mission critical system do change, as new features do get added (communications gear is a good example of a critical system with low-medium requirement churn), but scrum is still, IMO, inappropriate, as the rate of change is generally far too low.
Scrum also seems to lead to a lot of rework. If you find a requirement buried in your product backlog which you hadn't previously considered carefully, you may find you have to rewrite a substantial ammount of design to add that requirement. Again, in a system where your requirement churn is high, this is perhaps unavoidable, but in most systems (especially mission critical systems) the majority of your requirements are known ahead of time, so all that rework just becomes waste. The waterfall model would serve you better.
Finally, Scrum has a few pitfalls. Since your product backlog is generally full of features, it's easy to end up doing things like assigning features to designers instead of subsystems. The "sprint" mentality also seems to make it easy to shirk the responsability of producing correct documenation. You can do (or fail to do) these things with the waterfall method too, of course, it just seems like Scrum almost promotes them.
As for "There's nothing inherent in any agile methodology that precludes CMMI compliance," I'll point you to the Agile Manifesto. Let's just look at those first two points here;
1) "Individuals and interactions over process and tools"
How does this relate to CMM?
"Success in Level 1 organizations depends on the competence and heroics of the people in the organization and cannot be repeated unless the same competent individuals are assigned to the next project. Thus, at Level 1, capability is a characteristic of the individuals, not of the organization." - http://www.dfas.mil/technology/pal/cmm/lvl1desc.ht m
So the first point of the Agile Manifesto seems to scream out CMM level 1.
2) "Working software over comprehensive documentation"
Even if you had excellent quality software with poor documentation, the software would be difficult to change and maintain, unless you assign tasks to people who are intimately familiar with the existing code base (Sound like CMM 1 again?). If a person moves to a new project, there is a siginifigant learning curve. This is compounded by the unfortunate fact that, at my company, developers are assigned features, rather than subsystems. A new developer must t
Re:Capability Maturity Model
on
QA != Testing
·
· Score: 4, Insightful
The problem is, there are two motives to reach CMM 3;
a) It looks good to our customers. b) It reduces our cost.
Companies that strive for motive A often will do their best to meet the requirements of CMM to the letter, without actually changing what they do on a day to day basis. "CMM says we need to have a baseline and configuration management for our code, so I want everyone to check their work into this new CVS thing, at least once a month", for example.
It's easy to "meet the letter" of CMM without at all meeting the intent. At my company, for example, there's a core group who is trying to push "scrum" as a software development methodology, and they make all kinds of bizzare claims that this is somehow consistent with CMM 3, pointing to specific wording within CMM, and making claims that such and such is equivalent to CMM, even if it doesn't quite meet it. Meanwhile, I try to envision a mission critical system like a 767, or a space shuttle, or an ambulance dispatch service produced with scrum, and it makes me afraid to go outdoors.
Some people are afraid of change.
Re:Testing - The Anti Quality Process
on
QA != Testing
·
· Score: 2, Interesting
He's an expert on process and software quality, not HTML.
But, you're right, his site is pretty deplorable.:P He said he wrote it in some Microsoft tool and keeps claiming he's planning on rewriting it. Sadly, my father is very much in the clutches of Microsoft.
Re:Testing - The Anti Quality Process
on
QA != Testing
·
· Score: 1
One would assume you can get Open Office by way of apt. It came with my distribution, so I'm not sure. The specific application you're looking for in the suite is called "Impress".
All that testing does is prove your program doesn't work.
Testing DOES find bugs which the developers missed, but it only finds a very small fraction of them (unless you spend an extremely long time testing. I worked this out a couple years ago, but I forget the exact numbers. Something like to remove 90% of the remaining defects in our software, based on historical defect discovery, it would take around 20-30 person years of test effort.
Testing is the most expensive tool you have to remove defects. When you find a defect in test, you have no idea where that defect is. Someone has to root-cause and fix the problem. When you find the defect in a code-inspection, you have your finger on it; you can fix the defect with a minimum of effort. Also, it is much easier to find defects in a code inspection than by testing (around 2-3 per hour versus about one per 2-3 hours, on our product).
Even better is in design inspection, since a fault in the design typically leads to multiple faults in the implementation. Even better yet is in requirements inspection.
So, if your QA plan doesn't cover these phases of your development, your QA plan probably needs some work.
The whole point of testing is to see how well the rest of your process worked. If you know how much effort you spent testing, and you know the rate of defect discovery, you can estimate the number of defects remaining in your product. If that defect count is too high, though, it is probably faster and cheaper to start over with a new process than it is to "test" the product until it is free of defects.
Capability Maturity Model
on
QA != Testing
·
· Score: 3, Interesting
An excellent example of how anecdotal evidence can lead you to incorrect conclusions.
The SEI was approached by the military a couple decades ago. The military had a problem; when it contracted out software development work, it would sometimes get back what it was looking for, it would sometimes get it on time. Sometimes it was late, sometimes it didn't work, sometimes it did the wrong thing, and sometimes they got nothing at all.
The SEI went about polling a large number of contractors, trying to see what was common amongst the ones who delivered. They found there was actually a very strong correllation between a number of processes and practices and high-quality under-budget software. The result is the Capability Maturity Model or CMM for short, which divides companies up into 5 "levels".
The kind of organization you describe is quite definately a "level 1" company, the kind with the highest risk, and the lowest quality. Most companies, even small ones, should strive to follow the practices of at least level 3, as the benefits are quite tangible; no more late projects, and vastly fewer defects.
I mentioned it in another post, but my dad has a good web site that deals with quality issues (IE only, unfortunately). And, if you're looking to improve the quality of your software, his current contract is going to expire soon.
Testing - The Anti Quality Process
on
QA != Testing
·
· Score: -1, Redundant
My father gave a talk at a Quality Assurance Institute conference last year entitled "Testing - The Anti Quality Process". You can pick it up here.
He also has a fairly imposing web page which unfortunately only works properly in IE.
Many people point to StarROMs and say that they can then sell the games with the ROMs installed. This is not the case either. StarROMs license prohibits the resale of the game licenses, and only the end user can purchase these ROM images, resellers can not.
I guess he's never heard of the "Right of First Sale". I couldn't find the license agreement on StarROM's site, but unless they were extremely clever, such a clause would likely not be legally enforcable (although, IANAL).
This is simply UltraCade Technologies and other publishers doing whatever it takes to protect our commercial interests and prevent other companies from stealing our market...
I wonder what will happen if another company tries to start "legitimately" selling arcade machines? What guarantees do we have that UltraCade is only going to go after "bad nasty pirates"? What assurances do we have that this won't be used to create a monopoly? We have none. In fact, we have the opposite; if UltraCade succesfully trademarks MAME, then they MUST pursue any infringing use of that trademark, otherwise they risk loosing it. This means the authors of MAME will have to enter into some kind of legal agreement with UltraCade, or else stop using the MAME name.
If your requirements include;
1) The ability to save games
2) Save games must be compact in size
3) Saving games must be done efficiently
Then your system architecture should take these requirements into account, and your architecture document should outline a clear and consistent scheme for saving games, and your design documentation for each module should identify which attributes need to be persistant and stored in a save game file, which do not, and which ones might optionally be saved on the PC version where disk space is a non-issue.
You should be able to come up with a fairly accurate estimate of a save-game file's size and the time it will take to create it before you start coding, based on the other requirements of the game. If you fail to meet the required sizes for your target platforms, you know you either have to ditch those platforms, or adjust the requirements of your game.
The method you describe is what as known as "hacking in a feature". This is how junior designers turn otherwise simple requirements into "walls". It is also how you end up spending 6 months writing code, only to re-work all of it because it "didn't work out".
It's frequently the difference between being profitable and being a failure.
Slashdot Mirror
I should clarify; in fly-by-wire, you still have all the hydraulics of course. The computer has to move the actual flight surfaces somehow, and it isn't going to do it with a function call alone. :)
Most fly by wire planes have manual backups.
Hmm... Let's clear up a few things;
A typical small aircraft has mechanical linkages between flight controls and flight surfaces. So, when I push forward on the stick, the stick pulls on a linkage, which pulls on a long metal rod (or possibly a cable), which pulls on another linkage, which moves the elevator (the flight surface which controls pitch).
Your typical old-school big-jet (like a 737 for example) uses a hydraulic system. When I push on the yoke, the yoke pulls a linkage, which pulls a rod or a cable, which moves another linkage, which move valves which control hydraulic pumps, which in turn move the flight surfaces. Hydraulics are used in big planes, because the forces required to move the flight surfaces would exceed what a human is capable of.
"Fly By Wire" is where I move a stick or a yoke, and it activates a switch or rotates a potentiometer, which sends a signal off into a computer, which then moves the appropriate flight surface.
There are no mechanical linkages between the flght controls and the flight surfaces in, say, an Airbus A320. So in the strictest sense, there is no "manual backup". There is a "manual control", wherein you cut the computer out of the decision making process, so the plane does exactly what you tell it to, rather than what it thinks you want to do based on your input (the closest analogy I can think of would be disabling traction control in your car, but that's a pretty poor analogy. See my other post in this thread for more information on the A320's flight computers).
From a pure "flight control" perspective, cutting the computers and autopilot and whatnot out of the loop, fly-by-wire is likely the most reliable of all methods, since you cut out a lot of mechanical linkages and pullies and other physical stuff (which will eventually fail, no matter what, it's all a question of mean-time-between failures), and replace them mostly with solid-state electronics, which have extremely low failure rates, and extremely long MTBFs.
Fly-by-wire also makes it much easier for you to build a computer which controls the plane, since all your flight surfaces are already "digitally controlled".
I've flown a class D Airbus A320 simulator before (and by flown, I mean as the pilot). Class D sims are so realistic, that most airlines will let pilots log time in the sim as time in the air.
A child of four could fly that plane.
Essentially, a good way to think about it is; the plane is always on autopilot, and if you take "manual control" you're feeding requests into the autopilot, which it may or may not honor.
For example; pull back on the stick and set the throttle to minimum. The plane will start to pitch up, and your airspeed drops off. Once you get close to stall speed, the plane will start increasing throttle to maintain speed. Once it runs out of throttle, it will start decreasing the angle of attack. Even if you give it hard over rudder, the plane simply will not stall.
I did a "flame-out" landing, with no fuel, Gimli-Glider style, and aside from the fact that I blew out some tires (no ABS when the engines are out on an A-320), I landed the plane no problem.
My cousin, who used to fly for Air Canada, said that by Air Canada rules, they had to fly under pilot control on takeoff until they were at 500 feet. After that, they could let the computer fly the plane to their destination AND LAND without further human intervention.
As far as concerns over "computer faults" go; the Airbus computer consists of (IIRC) 7 processors, which all vote to determine what to do. If a given processor disagrees or starts acting wonky, it gets rebooted. Each of these 7 processors is running different code, based on different designs, by different teams of software engineers. The only thing they have in common is that they were developed from the same requirements.
This is kind of like saying "I need to continue to grow my per day spending. I need to find new and more plentiful ways to make money. Having lots of money has change my life, where I live, etc... I'm not sure I can afford a yacht any time soon, but If could, wouldn't that be cool?"
It's true; spending energy is fun and has many positive benefits, but at the moment our primary energy source is oil, and it isn't renewable. One day, maybe we'll have some new, safe, and more plentiful energy "income" sources, but right now we don't. When you're out of work, spending all your cash reserves is a dumb thing to do, and that's what we're doing with oil, right now. There's no "energy Visa company" we can borrow from while we're out of oil and waiting for fusion or high-altitude wind generation, either.
It is, in fact, even worse than the cash analogy; development of new energy technologies requires energy. If we let our energy reserves drop low enough, eventually we won't have the resources required to invest in new energy technology. It's like driving down the highway, and being close to empty. It's nice that there's a gas station 40 miles up the road, but if you keep the pedal to the metal, and burn up all your gas in 20 miles, you're still fscked.
Since you can't feel the keys, you have to be looking at the keyboard to use it. The last time I had to type on such a keyboard, with no "tactile feedback", was on an old Timex Sinclair 1000.
It was neither a fun nor pleasant experience.
Here's a photo of the device, and some more info. The price is $99 USD.
You'd think you'd be able to smooth out mouse input in software. I admit, the platform independant aspect is nice, but still...
I wonder what kind of filtering they do for "inadvertant clicks"? Clicks associated with mouse movement? Triple clicks?
Well, aside from the fact that whenever I try to search or search and replace, it crashes. Anjuta looks very promising, but it doesn't seem very stable. I'm eagerly awaiting the 2.0 release.
All you need is the ability to trap all the energy from both stars. Some kind of container whose inside is it's outside. I predict this will give rise to a whole new industry in Dyson-Klein Bottles.
If you're into the tile based games, Zombies is kind of interesting, although IMHO it's a little overly random, and not nearly as interesting as the other games you listed. Still, it's fun.
A game we've been playing lately is Filty Rich, a "3D" board game by Richard Garfield (creator of, amongst other things, Magic: The Gathering). The idea is you open shops, and then collect income from them, with the objective being to be the first one to buy three luxuries (trophy spouse, patent of nobility, private jet, etc...). The "game board" is a binder with four 3x3 plastic card-protector sheets inside. When you open a shop you place it's "sign" into the card-pockets on the sheet (a sign could span multiple pockets), then you roll some dice to see which pockets get visited, and collect income, and then there's a 50% chance you'll move to a new random page.
The game is "3d" since on a given page you can "see through" to pages underneath. It's quite a clever and fun little game. You can see the rule-book at the link above, if you're curious.
So what metrics do you use? Do you just tell your team to get their defect/kloc down, without giving them any kind of plan or direction as to how?
The fact of the matter is, if you have a process, and you follow it on two different projects, you'll get two products of very similar quality at the end. If you don't follow a process, you'll get two products of random quality at the end.
CMM 1 you get for free. CMM 2 gives you guidelines as to how to establish a process, so you'll be "repeatable". CMM 3 gives you guidelines as to how to make your process better. When you get up into CMM 5, you have a process that makes itself better.
Again, you have to implement the "intent" of CMM, not the "letter". You don't want to measure your team against CMM, you want to use CMM to reduce your defects/kloc and your effort/kloc.
If only you could adapt the same algorithm to software...
Come on, one of the cornerstones of our culture is "Mistrust authority, promote decentralisation". It really hurts to see authoritarian systems being promoted like that.
When you start talking about open source, I'd agree. But, when you talk open source, you're talking about a whole different beast. Most OSS projects have no Quality Assurance to speak of, other than the discipline applied by the developer to his own work. There are a lot of different discussions about why OSS succeeds, despite doing most of the things that classical engineering would shun, but regardless of which arguments you buy or don't buy, two things are obvious; OSS works, and the bazaar is nothing like the cathedral.
Once you start talking about the cathedral, you're no longer talking about our culutre, you're talking business. At the end of the day, I'd rather get my for-work projects done before the deadline with a minimum of fuss, so I can go home and work on more interesting projects. In order to do that, though, I need to the cooperation of the people around me, many of whom are not uber-hackers like you and me, but people who got into computers because that's where the money is, even though they'd really rather be doing something else.
The cathedral requires a common process which everyone must follow, otherwise we end up working late, past deadline, over-budget, and eventually go under.
This is an interesting argument, and it's one I hear a lot here, but let me ask you something;
What was your improvement in productivity, and how was it measured? What was the reduction in your (delivered defects):(effort expended) ratio? What was the reduction in your (lines of code delivered):(effort) ratio? One or both of these ratios have to go down.
If you don't have these numbers, you can't really say you've improved productivity, especially with a process like Scrum. Scrum makes it very easy to think you're more productive, because it gives you results every 30 days (in fact, to a lesser degree, every single day with your Scrum meeting). But are you actually more productive? There's a fair rework cost incurred by Scrum, due to the constant introduction of new requirements, which Scrum hides very well.
I don't have these numbers either, and I'm not sure if anyone has done such a study (although I've encouraged the group here that's pushing Scrum to measure them), so I can't say for sure which process is "better" from this perspective.
I will agree that Scrum does an excellent job of making developers feel good, which is one of their stated aims, but unfortunately, software exists not to please its developers, but to please its users.
Or, there's something wrong with the certification. Or, the company lies to get certified.
I've worked in a few ISO 9001 certified shops which really didn't come close to ISO 9001.
Why? Would you expect the head of process quality of Ford to be able to spin off perfect HTML? And if so, why? It's not even related to his job.
:) and he hasn't had time to rework it.
Believe me, I've encouraged him to redo his site, but he wrote it using some MS product, which generates IE-only HTML (likely a requirement of any MS software
I'm not calling Scrum bizzare. Scrum seems like a good way to develop a piece of software where the requirements churn is very high. I have a hard time thinking of such a system off the top of my head. It might be an acceptable way to develop a low-churn system where you want your time-to-market to be next to zero, provided the cost of a failure is very low, and redeployment costs are minimal, and you don't mind burning some cash down the road to get to market first. A web-based email system, for example, might be a good candidate for scrum. I'd also think that you would need a fairly small team size for scrum to work properly, although I don't have data to back that up.
A mission critical system, though, where the cost of failure is high (say, death), is not really a good candidate for Scrum. If you worked at Boeing and found "777 left wing" in your process backlog, you'd probably want to seek employment elsewhere.
With any mission critical system, you need a very clear understanding of the requirements before you start design - otherwise there is a high probability that your design will fail to meet one of those requirements, and therefore the system will likely fail. The whole point of scrum is that you basically make up features (and, therefore, requirements) as you go along, and hack them in. Your product backlog is basically just a list of features you want but haven't had time to hack at yet.
The requirements of a mission critical system do change, as new features do get added (communications gear is a good example of a critical system with low-medium requirement churn), but scrum is still, IMO, inappropriate, as the rate of change is generally far too low.
Scrum also seems to lead to a lot of rework. If you find a requirement buried in your product backlog which you hadn't previously considered carefully, you may find you have to rewrite a substantial ammount of design to add that requirement. Again, in a system where your requirement churn is high, this is perhaps unavoidable, but in most systems (especially mission critical systems) the majority of your requirements are known ahead of time, so all that rework just becomes waste. The waterfall model would serve you better.
Finally, Scrum has a few pitfalls. Since your product backlog is generally full of features, it's easy to end up doing things like assigning features to designers instead of subsystems. The "sprint" mentality also seems to make it easy to shirk the responsability of producing correct documenation. You can do (or fail to do) these things with the waterfall method too, of course, it just seems like Scrum almost promotes them.
As for "There's nothing inherent in any agile methodology that precludes CMMI compliance," I'll point you to the Agile Manifesto. Let's just look at those first two points here;
1) "Individuals and interactions over process and tools"
How does this relate to CMM?
"Success in Level 1 organizations depends on the competence and heroics of the people in the organization and cannot be repeated unless the same competent individuals are assigned to the next project. Thus, at Level 1, capability is a characteristic of the individuals, not of the organization." - http://www.dfas.mil/technology/pal/cmm/lvl1desc.ht m
So the first point of the Agile Manifesto seems to scream out CMM level 1.
2) "Working software over comprehensive documentation"
Even if you had excellent quality software with poor documentation, the software would be difficult to change and maintain, unless you assign tasks to people who are intimately familiar with the existing code base (Sound like CMM 1 again?). If a person moves to a new project, there is a siginifigant learning curve. This is compounded by the unfortunate fact that, at my company, developers are assigned features, rather than subsystems. A new developer must t
The problem is, there are two motives to reach CMM 3;
a) It looks good to our customers.
b) It reduces our cost.
Companies that strive for motive A often will do their best to meet the requirements of CMM to the letter, without actually changing what they do on a day to day basis. "CMM says we need to have a baseline and configuration management for our code, so I want everyone to check their work into this new CVS thing, at least once a month", for example.
It's easy to "meet the letter" of CMM without at all meeting the intent. At my company, for example, there's a core group who is trying to push "scrum" as a software development methodology, and they make all kinds of bizzare claims that this is somehow consistent with CMM 3, pointing to specific wording within CMM, and making claims that such and such is equivalent to CMM, even if it doesn't quite meet it. Meanwhile, I try to envision a mission critical system like a 767, or a space shuttle, or an ambulance dispatch service produced with scrum, and it makes me afraid to go outdoors.
Some people are afraid of change.
He's an expert on process and software quality, not HTML.
:P He said he wrote it in some Microsoft tool and keeps claiming he's planning on rewriting it. Sadly, my father is very much in the clutches of Microsoft.
But, you're right, his site is pretty deplorable.
One would assume you can get Open Office by way of apt. It came with my distribution, so I'm not sure. The specific application you're looking for in the suite is called "Impress".
All that testing does is prove your program doesn't work.
Testing DOES find bugs which the developers missed, but it only finds a very small fraction of them (unless you spend an extremely long time testing. I worked this out a couple years ago, but I forget the exact numbers. Something like to remove 90% of the remaining defects in our software, based on historical defect discovery, it would take around 20-30 person years of test effort.
Testing is the most expensive tool you have to remove defects. When you find a defect in test, you have no idea where that defect is. Someone has to root-cause and fix the problem. When you find the defect in a code-inspection, you have your finger on it; you can fix the defect with a minimum of effort. Also, it is much easier to find defects in a code inspection than by testing (around 2-3 per hour versus about one per 2-3 hours, on our product).
Even better is in design inspection, since a fault in the design typically leads to multiple faults in the implementation. Even better yet is in requirements inspection.
So, if your QA plan doesn't cover these phases of your development, your QA plan probably needs some work.
The whole point of testing is to see how well the rest of your process worked. If you know how much effort you spent testing, and you know the rate of defect discovery, you can estimate the number of defects remaining in your product. If that defect count is too high, though, it is probably faster and cheaper to start over with a new process than it is to "test" the product until it is free of defects.
An excellent example of how anecdotal evidence can lead you to incorrect conclusions.
The SEI was approached by the military a couple decades ago. The military had a problem; when it contracted out software development work, it would sometimes get back what it was looking for, it would sometimes get it on time. Sometimes it was late, sometimes it didn't work, sometimes it did the wrong thing, and sometimes they got nothing at all.
The SEI went about polling a large number of contractors, trying to see what was common amongst the ones who delivered. They found there was actually a very strong correllation between a number of processes and practices and high-quality under-budget software. The result is the Capability Maturity Model or CMM for short, which divides companies up into 5 "levels".
The kind of organization you describe is quite definately a "level 1" company, the kind with the highest risk, and the lowest quality. Most companies, even small ones, should strive to follow the practices of at least level 3, as the benefits are quite tangible; no more late projects, and vastly fewer defects.
I mentioned it in another post, but my dad has a good web site that deals with quality issues (IE only, unfortunately). And, if you're looking to improve the quality of your software, his current contract is going to expire soon.
My father gave a talk at a Quality Assurance Institute conference last year entitled "Testing - The Anti Quality Process". You can pick it up here.
He also has a fairly imposing web page which unfortunately only works properly in IE.
Many people point to StarROMs and say that they can then sell the games with the ROMs installed. This is not the case either. StarROMs license prohibits the resale of the game licenses, and only the end user can purchase these ROM images, resellers can not.
I guess he's never heard of the "Right of First Sale". I couldn't find the license agreement on StarROM's site, but unless they were extremely clever, such a clause would likely not be legally enforcable (although, IANAL).
This is simply UltraCade Technologies and other publishers doing whatever it takes to protect our commercial interests and prevent other companies from stealing our market...
I wonder what will happen if another company tries to start "legitimately" selling arcade machines? What guarantees do we have that UltraCade is only going to go after "bad nasty pirates"? What assurances do we have that this won't be used to create a monopoly? We have none. In fact, we have the opposite; if UltraCade succesfully trademarks MAME, then they MUST pursue any infringing use of that trademark, otherwise they risk loosing it. This means the authors of MAME will have to enter into some kind of legal agreement with UltraCade, or else stop using the MAME name.
If your requirements include;
1) The ability to save games
2) Save games must be compact in size
3) Saving games must be done efficiently
Then your system architecture should take these requirements into account, and your architecture document should outline a clear and consistent scheme for saving games, and your design documentation for each module should identify which attributes need to be persistant and stored in a save game file, which do not, and which ones might optionally be saved on the PC version where disk space is a non-issue.
You should be able to come up with a fairly accurate estimate of a save-game file's size and the time it will take to create it before you start coding, based on the other requirements of the game. If you fail to meet the required sizes for your target platforms, you know you either have to ditch those platforms, or adjust the requirements of your game.
The method you describe is what as known as "hacking in a feature". This is how junior designers turn otherwise simple requirements into "walls". It is also how you end up spending 6 months writing code, only to re-work all of it because it "didn't work out".
It's frequently the difference between being profitable and being a failure.