Which of these certifications is the best for a sofware company?
Printable View
Which of these certifications is the best for a sofware company?
Hi ,
IMHO , ISO or CMM is mostly relevant for service organization or product development companies ( contract ) who work for defence agencies or Overseas development centeres.
To have a process in place , all organizations ( at least in india ) start with ISO. ISO has got the advantage that there will be survilence audit and it is given for a stipulated period only. Once an organization has practiced ISO for at least 2 years , they can judge the maturity of the process by CMM level 3 audit . ( i have seen some companies going straightaway for five. It is equivalent to going to a college just a certificate. )
CMM , once accessed , is a permanent thing. But ISO practices are to be followed so as to ensure process integrity and maturity.
We need both , if we are serious about Process quality.
Praseed Pai
www.praseedpai.com
ISO9000 + Six Sigma
well ISO standards were good in the beginning, now CMM is used (best to have). CMM has even a new successor called CMMI
Voted for ISO 9001.
I don't know very much about CMM, but somebody told me that CMM Level 5 means you have nomore bugs reported by the client.
Is this posssible :confused:
Sounds like SF.
Hi ,
CMM is to assess the maturity of the process followed in an organization. The whole process is divided into KPAs ( Key process areas ). KPAs are distributed
into following five phases
Initial
Repeatable
Defined
Managed
Optimizing
It will help to ensure that things are predictable.
>
>but somebody told me that CMM Level 5 means you have nomore bugs reported >by the client.
>Is this posssible
>Sounds like SF.
>
CMM ( at least as specified by SEI ) does not claim it.
Six sigma initiative is to minimize the error . ( 3 bugs for 10,00,000 LOC etc )
Praseed Pai
www.praseedpai.com
Thanks everybody voted and added comments to this poll!
To Praseed Pai:
It seems to be a typing error in your last post.
May I understand 3 bugs for 10,000,000 LOC?
Is it possible? Of course, excepting the case when those10.000.000 are blank lines. :DQuote:
Originally Posted by SOCM_FP_CPP
Hi ,
>
>PadexArt
> Is it possible? Of course, excepting the case when those10.000.000 are blank > lines.
I feel , Padex has worked only as a solo programmer ( a lone wolf....i do not mean to offend him ). Industrial strength software development ( using a team ) needs to have well defenied and robust process to deliver the software on time without deviating from the objective of the software project. Six sigma intiative has helped companies to improve their productivity and minimize the number of error which can arise.
It is just like asking How many cops are necessary for controlling a mob of 1,00,000 ? a mercenary will think that u need 1,00,000 cops. But a policeman worth his salt understands that not more than 5,000 well armed policemen are necessary .
When u think software development as programming , it is hard to believe that only three errors can arise in case of 1 million LOC. When u treat programming is only one aspect of software development , one can make sense of ISO,CMM or Six sigma.
Praseed Pai
It always amazes me the defeatist attitude when it comes to software defects. You do realize software runs in medical devices among other things. Would you be fine with ohh > 3.4 defects per million opportunities in that 12 lead they have you hooked up to? How about a ventilator?
It's all about your processes. Is ISO and Six Sigma name recognition...well you bet so fork out the dough but they are also proven processes.
I get dinged alot because I advocate zero defects. Sometimes I really don't understand the nonchalance of my fellow developers.
This is true SOCM_FP_CPP. :) And I'n not at all offended. I've mostly worked alone or in small teams ( up to 7-8 people). The largest project I took part in was about 1.000.000 LOC.
Nevertheless it seems that is rather difficult, if not impossible, to have such a small number of errors in a large scale project ( even in medium sized ones - like the one I've menioned).
And it is quite more difficult if more people are involved into the process. I don't mean only programmers. From my experience, the most difficult task is to have a correct understanding on the client's needs. As a consequence the specifications can and usually are flawed or they are incomplete, in the best possible scenario.
So if we are to consider a project as a whole, from the moment the 1st contact was made with the client until the moment when the product is installed, with manuals, examples and everything I find quite hard to achieve the "n errors" goal.
Yet, there might be something I'm missing here. Perhaps something as simple as the definition of the "error" in the process you are mentioning.
:) I don't advocate for buggy code. I only state it is rather difficult to get a product with 0 deffects from the first attempt. This under the normal circumstances of having time/cost pressure from the client.Quote:
Originally Posted by Mick
Which is why you have a 'process' :)Quote:
Originally Posted by PadexArt
You also have to follow that process. I spent a couple of years with a large corp. that had a very good process. But they didn't f'ing follow it, customers/marketing/sales pushs a bit and management folded. End result was crappy code, crappy documentation, crappy everything, cost time/money and my sanity :)
True Mike. :) But does implementing a process necessarily mean one will achieve the advertised results? I can understand that if the process is correctly implemented the outcome is a better product with fewer errors. But can you guarantee that the number of errors is bellow 1 or 10 or even 1000? And how do you verify it? This is difficult to say for a 100 loc application.Quote:
Originally Posted by Mick
Look at UML for an example. When it was introduced many thought that that was the end of the specification nightmare. A nice & simple visual language and many processes ( like RUP) to bridge the gap between the "manufacturers" and the clients of software products, and not only.
Can you tell me today that that problem is solved by simply using UML and any of the processes available?
EDIT: "You also have to follow that process."
I agree 100% on this one. :wave:
Process is important. What process should be used by a particular company or group of developers is a complicated question. It depends on the size of the development team, the number of years they have worked together, the amount of discipline they have, the amount of domain knowledge they have, how closely they can work with the customer, who the customer is, the complexity of the project, and the lifetime of the resulting product. You want to spend sufficient amount of process-related effort to meet the project goals, but not an ounce more.
As an example, a game company can't afford to follow a heavy-weight process, while a real-time medical software company can't afford NOT to.
The right group may achieve a better project in less time using XP (eXtreme Programming) rather than RUP or Six Sigma.
My take on the CMM:
There's good stuff in the CMM, but there's very little reason for certification. It's expensive and there's little benefit unless you are a defense contractor. Take what you need from the CMM, and ignore the rest. Trying to follow the CMM fully will be horribly wasteful and you'll end up pushing around paper more than pushing around bits.
Again, process is important. Do your research. Find a good one and then adapt it to your group and company.
Personally I prefer more agile processes, but the managers here come from an older school. We end up with a mix of XP and RUP and even a little waterfall(ugh). We constantly reevaluate our process and try to improve it. Right now we are focusing on how to better handle requirements and how they should feed into design.
Jeff
ISO 9000 : dirty Water purified only when audit comes.. again will become dirty, it will be purified few days before audit.
CMM : dirty water purified only once... wait untill client gets a feel that we are using dirty water.. again purify starts..
Six Sigma :dirty water purified once and kept in control..
Nice definitions. :thumb:Quote:
Originally Posted by santoct2002
Please explain by short how keeps Six Sigma under control the purified water.
It has DMAIC and DFSS to keep track every SigSigma PROCESS , You can get more details in following page..Quote:
Originally Posted by ovidiucucu
http://www.isixsigma.com/dictionary/DMAIC-57.htm
But also ISO 9001:2000 states the PDCA (Plan Do Check Act) cycle, that can keep the water clean between two audits.Quote:
Originally Posted by santoct2002
Well, as I know, ISO9001:2000 introduces also the notion of "zero defects".Quote:
Originally Posted by Mick
But we cannot say that every bug in a software product is a defect.
Maybe at one moment the caption of your medical application can irritate few old nurses when upgrading the hospital computers OSs from Windows 2000 to XP. This is not a defect, it's just a nonconformity that can be easely fixed.
You and another individual seem to be missing my point. I think maybe people need to pause and try and differentiate between opinion and fact. There is a big difference between reading about it and being responsible for implementing it. Getting a group of 'sensitive' developers to take responsibility for defects in their code has always been met with resistance in my 15+ years of experience.Quote:
Originally Posted by Hokutata
It is a pet peeve of mine so I hope that clears it up for you guys. If not, it still doesn't change the facts that I have observed whether in management at the time or one of the developers being asked to buy into following the guidelines.
Maybe they just cut east coast developers out of a different mold and your mileage will vary. :p
I came to work and tore off the page of my 2004 Dilbert desk calander. It's Dogbert talking to the pointy haired boss:
Dogbert: You've got to implement a six sigma program or else you're doomed.
Boss: Aren't you the same consultant who sold us the worthless TQM program a few years ago?
Dogbert: I assure you that this program has a totally, totally different name.
Boss: When can we start?
Just thought it was an amusing coincidence.
Jeff
Defect "management" is always an interesting topic. There is so much hype that real issues often get overlooked. Just a few notes:
1) An error in something (such as a peice of code) is NOT a bug or defect, DURING THE TIME IT IS IN DEVELOPMENT. It becomes one when either of the following occurs:
a) The test plan for this phase is not sufficient to catch the error
b) The test plan is not properly executed.
If a test is executed within a phase catchs an error, and the error is corrected without the project leaving that phase, then this is merely another cycle of the local iterative process.
The first can be dealt with by having an iterative test process and a good grasp of CDRIL principals [internal analysys to determine the set of stimuli that is needed to exercise all possible operations]. The second can be dealt with only by a strong incentive policy known as "Keep your job".
2) One guarenteed way to avoid ALL errors and defects is to have no specification. If there are no requirements specifying what the program must/should/can do as well as those items which it can't/shouldn't do, then any operational behavour can not be deemed incorrect. :eek:
Just as an interesting note, my wife is the Senior administrative assistant to the global chief engineer of Underwriters Laboratories, which is one of the largest certification agencies in the world.
I've worked in a German company that dables in this. No, there are no more bugs. However, the number of bugs that are reported by the customer are greatly reduced.Quote:
Originally Posted by marsh_pottaye
But this generally happens: in every company/project the number of reported bugs decreases in time.Quote:
Originally Posted by YourSurrogateGod
At least in Europe, ISO9001 is pretty enough. It's a nonsense to try others, even googling "CMM" + "certified" + "India" (just for an example) you'll find tens of thousands of results.
Quote:
Originally Posted by micknustiunimik
What do you trying to convey here? I could not understand ? Why India? Why you are searching in Google?? ... I am not able to understand.. plz explain. :confused:
1. He/she said: "just for an example".Quote:
Originally Posted by santoct2002
2. What are you not able to understand why somebody is searching in Google?
Besides, if you do search using that query you'll find 13.800 results. This could mean that CMM is a fairly popular standard in India ( and also Pakistan from the results).Quote:
Originally Posted by ovidiucucu
That's pretty good, isn't it? :)Quote:
Originally Posted by PadexArt
As mentioned earlier... people quoting standards does NOT imply people/companies FOLLOWING standards.
There was a company here in the Northeast US who mandated different color binders for material that confirmed to ISO standards and a different color binder for all documentation which did not follow the standards.
If an audit was scheduled, all non-conforming binders were removed from the building. If an unscheduled audit occured [or a customer visit] the binders were removed from sight. There was even an overhead page that was coded to mean "Hide the D*&mn Evidence NOW!"...
While this situation MAY have been extreme, it is VERY simular to practices at many companies.
Nice... :)Quote:
Originally Posted by TheCPUWizard
A question: in your opinion, this is good or not for an individual programmer?
I mean, in the product development process, by skipping some "annoying tasks" required by the standard, e.g. writing some documents, a programmer can gain more time to spend writing code...
A LOUD and resounding NO!!!!!!Quote:
A question: in your opinion, is skipping some "annoying tasks" required by the standard, e.g. writing some documents, a programmer can gain more time to spend writing code...good or not for an individual programmer?
When you are an individual programmer [or are involved in a small team] the advantage you have is that YOU get to set the standard ;)
If you want to succeed you pick a set of "rules","concentions", and "preceedures" and stick to them. And there are major benifits to doing so.
If you adopt the "fast and loose" "standard", you know that you will produce lots of code, which is likely to have bugs, not be overly re-usable, etc. Onb the other hand, you will produce it fast.
If you follow a stronger set of "standards" or "guidlines" CONSISTANTLY, you will really get to know what to expect from your code. This allows you to plan much more effectively, and will improve experiences with your customers.
When in many corporate environments, the biggest problem I see the the Dilbert "Pointy Hired Boss" effect. A manager making decisions about which standards to follow [or break, or ignore] without having a true understanding of their impact on the development process.
The two places that not having a set of standards cause problems are:
1) You do not establish consistancy and good habits. This can cause problems if you are a solo programmer and end up working with larger teams in the future. The "does not play well with others" syndrome.
2) You do not know what to expect from the code your are producing. Say you typically follow a set of moderate procedures. You have learned that a given task will typially take 3 weeks to design, 1 week to code, and 2 weeks to test [these are some good ballpark ratios [IMHO]. You decide to short-circuit your normal way of doing things and start coding after just one week of design. The coding tajkes two weeks and your firuge you are a week ahead of the game. Unfortunately testing revels some serious bugs and takes over a month to successfully pass!
Of course, NOT. That is also my opinion.Quote:
Originally Posted by TheCPUWizard
However, 3 weeks to design/1 week to code (IMHO) looks a little bit exaggerated ratio.
I remember a story, not sure it's really true, but quite nice.
I a Western Europe company, the managers decided that for a sofware product they don't need anymore programmers because they have already in the company good analysts and can acquire a good design tool that automatically generates code. So that they done.
After months of work all "looked" perfect.
But two days before deadline, when they generated the code and built... they had, ready to be delivered, a little cute two-gigabyte executable... :D
It very much depends on the definition of design vs coding :DQuote:
Originally Posted by ovidiucucu
Imagine that you need to write a computer program to perform a specific task. You need to define the task with sufficient detail that you could post it in any of the programming forums here on CodeGuru, and a [competent] programmer could implement it in the language in which that forum was based. If the specification is sufficiently detailed then all of the resultant programs should have identical functionallity.
Clearly all work done during this phase is design (The programming language has not even been defined). Now lets restrict the target programming environment a bit (again a design issue) and determine that we want to use .NET [the pros/cons of this are another topic!]. Here we are still language neutral [it could be managed C++, VB, C# or a third party compiler]. More design decisions need to be made regarding the portions of the CLR that will be used, how assemblies will be organized, which collection classes will be used for managing groups of data, etc. This is STILL design work.
Only when we get down to translating these desicisons into the proper syntatical format for the target languae, are we actually coding. This is where the old definitions of "analyst" being used to mean the one who does the design, and "programmer" being used to mean the one who does the "coding" completely fall apart.
Clearly during the implementation there will be choices as trivial as deciding if a certain loop will be a while" [conditional at top of loop, with possibly 0 iexectuions of the loop] or "do" [conditional at bottom of loop, with at least 1 exeuction of the loop]. This is a design decision. The coding issues relate to the proper use of parenthesis, semicolons, braces and the like.
Aha...Quote:
Originally Posted by TheCPUWizard
Do we need flow diagrams (as a design issue) to show programmers what loops to use for implementing functions?
Are you still programming in Cobol, Fortran...?
In general NO. Can we say that these types of diagrams are never needed? I think the answer to this is also no.Quote:
Do we need flow diagrams (as a design issue) to show programmers what loops to use for implementing functions?
MY point however was quite different. The old shool of thought divided design and implementation into analysts and programmers. This division had many implications. Most modern shops freely combine design and implementation tasks and have them performed by a single person. The assignment of tasks to specific individuals or groups is more often related to the scope or placement in the hierarchy. This is similar to the structre of many armed forces. Division between stratigic and taactical issues.
Want I wanted to ifocus on is that if you are sitting in front of a computer and tring to decide what type of loop, container, or other technique to use, you are involved in design. When you make your choice and have to figure out what the "magic incantations" are to do this within a specific environment [language, compiler, library, etc], then you are programming.
Spend a day in front of the computer. being aware of what you are doing [so much of this is automatic to people with any serious experience]. Are you trying to decide what you want to do, or are you specifically thinking of "how to explain that to the computer". For most, it becomes quickly obvious that Programming/Coding is a very very small part of the time spent. The ramification are startling...
Assume I spend one day talking with people about what a program should do, followed by three days building the software, followed by day of testing. The thought could be:
But if we review are time at the keyboard more closely, we find that 25% of each day was actually spend on programming in the context outlined above, 50% in desgin related thoughts and actions and 25% is testing [which can take many forms both tangible and intangible) whave:Code:Design 20%
Programming 60%
Testing 20%
The programming is a mere 15% of the total time spend on the project!!!!!Code:Design 1 + 0.50*3 = 2.5 days
Programming 0.25*3 = 0.75 days
Testing 1+0.25*3 = 1.75 days
There are over three days of design work per day of programming work!
There are over two days of testing work per day of programming work!
The numbers become even more extreme when one factors in the time typically spend on a project at the very beginning of the cycle and after the "first version" is deemed to be "working".
Occasionally. There are a lot of legacy systems out there. Interestingly enough I did a Cobol.NET contract earlier this year.Quote:
Are you still programming in Cobol, Fortran...?
Cobol.NET? Quite interesting. Serious.Quote:
Originally Posted by TheCPUWizard
Just I'm courious: there is also an Assembly.NET? Should be even more interesting.
Cobol .NET is quite real [Micro Focus has a complete range of current Cobol products!]. It serves two main purposes:
1) Bringing legacy code into new environments and platforms
2) Allowing Cobol programmers to be productive without having to go through a large transition.
While I tend to have some serious issues with the second purpose, I do concede some validity [I have had direct discussions with some of the senior people at MicroFocus on this issue].
--------------------
You can program directly in MSIL [which is the "assembler" level of .NET], howver an x86 style assembler would be quite counter productive [since the output of it would have to be MSIL which is a "higher" level language].
You made me nostalgic...
Just I have remembered the good days of highschool,...learning Cobol 74... :)
Me too... :DQuote:
Originally Posted by Hokutata
I think, since Y2K area has been closed, the interest for Cobol 74 is also closed. :D
lol, isnt six sigma a manufacturing quality control control thing?Quote:
Originally Posted by Mick
*lol* it's 2004. You need to catch up with the times. Try some research...Google is a good place to start.Quote:
Originally Posted by Cerf
If I am not wrong, it first started from manufacturing. Since then it has been brought over to software. See the following link.Quote:
Originally Posted by Cerf
http://www.softwaresixsigma.com/