Software Releases - When do you release a software product?

Marc

Hunkered Down for the Duration
Staff member
Admin
#1
Subject: Re: Software Release /Roque/Dey
Date: Tue, 8 Jun 1999 10:33:23 -0600
From: ISO Standards Discussion

From: Pat Dey
Subject: RE: Software Release /Roque/Dey

> From: maryanne_roque
> Subject:Q: Software Release /Roque
>
> Is there any one out there who could give me some input as to :
> a) when do you release a software product

When you are confident that you will earn more from revenues than you will lose in the cost of fixing problems you overlooked.

That sounds cycnical. But if you consider costs in their widest sense, it's in everyone's interests.

If you're selling low price high volume software, you might not want to wait until it's 100% bug free: Microsoft and many others have shown that first to market wins -- and the market will buy software that's "good enough" provided it's cheap enough. (Sure, there are complaints and you have to factor in the cost of fixing complaints and consequent loss of business.)

For low volume, high price custom software the cost of problems will usually include higher support costs, reduced customer referenceability. Ultimately, poor quality can cost current and future contracts and consequently you will probably want to be pretty confident it's good before release.

> b) how do you classify test failures (minor, major, catasthropic?)

In terms of the cost to the customer, eg,

Severity 1 - castrophic, no workaround (eg engine will not start)
Severity 2 - major functional failure, workaround exists (engine starts, must keep revs up)
Severity 3 - minor functional failure (turn signals don't work)
Severity 4 - cosmetic (don't like digital dash, prefer analog instruments)

> c) when there are bugs found during system (integration) test, do you
> still release the product?

If custom software, no severity 1 or 2 bugs unless customer agrees to take delivery, eg, to start their integration test.

Most important thing here is openness with the customer.

> d) any reasons of not releasing a product to the customer?

Existence of severity 1 or 2 bugs that will cause customer serious expense. Worst is to deliver knowing such problems exist and wasting customer's time (= money) finding them and reporting them back to you (not to mention their loss of confidence in you).

Better to be late and right than on time and wrong, in my view.

> e) how do you track test failures?
>
There are several bug tracking tools out there which enable you to keep a list of open issues, prioritize them, assign them to people and track them to closure. Try the Configuration Management Yellow Pages at *** DEAD LINK REMOVED *** for an extensieve review of the subject. You can spend as many or as few bucks as you like. Important thing is to define a tracking discipline and get buy-in from the engineers involved.

> Appreciate any input that I will receive from you fellows.

Good luck,
Pat
 
Elsmar Forum Sponsor

Marc

Hunkered Down for the Duration
Staff member
Admin
#2
Subject: Re: Q: Software Release /Roque/Borges
Date: Tue, 8 Jun 1999 10:56:58 -0600
From: ISO Standards Discussion

From: Eliana Borges
Subject: RE: Q: Software Release /Roque/Borges

I will give it a shot, hoping this will help:

> a) when do you release a software product

When it meets the criteria for developing it. A criteria, I hope, was developed with the customer's success in mind. The software will be as good as the spec that was approved for its development. Hopefully the customer does have a representative speaking for them. Unfortunatelly, for all of us, some software is developed without much thought as to our success. And many of us may spend many hours dealing with it. Without mentioning something specific, think of all the products out in the market that are very quick to go to sale and then deal with the problems later, through customer support lines and "patch" or new releases of the product. There is a balance here - time to market versus risking the products name, versus customer support. It is really a team decision based on a study of facts. There should be someone running the project who is used to making such decisions and drawing the line. Someone has to make a decision as to when to "stop developing it" and to get it out. It is not an easy one, especially if the top spec and lower level specs were not well prepared. But the answer is still the same: stop when it meets the spec. Leave improvements for the future.

> b) how do you classify test failures (minor, major, catasthropic?)

You could use some self developed guidelines or look into industry standard guidelines. The good old military specs used to give us classification of defects and configuration control rules defining things as minor, major and critical. Minor and major are easier to understand. Critical was left for things that affected the loss of human life or property. Define the failure in respect to meeting the spec and meeting the user's needs - then classify it accordingly. What exactly do you mean with catastrophic? If you are dealing with regulated industries the classifications would be spelled out for you in the regulations or contract.

> c) when there are bugs found during system (integration) test, do you
> still release the product?

Does the product still meet the spec? What are the implications of the bug - how does it change what the software need to do? During integration we would hope you will run many test cases to ensure performance. If a bug is introduced the whole software configuration is now compromised because you do not know what other things may go wrong because of the bug. The least you can do is fix the bug and retest from the start.

> d) any reasons of not releasing a product to the customer?

All of the above plus the fact that it is unethical, and ruins careers and companies.

> e) how do you track test failures?

By developing a good failure reporting system which involves multi disciplinary functions and implements effective preventive and corrective action. Better than tracking test failures is preventing failures by breaking the test into small pieces and avoiding the enourmous task of trying to test it all at once. Integration should be the final rehersal of the orchestra, after all the instruments were already playing well together, all of them tuned up separately but working well with the others.

I hope I have given you some food for thought. And I hope the software you are talking about is not critical to the human race. And if it is, take good care of it.

Regards,

Ellie Borges
 

Marc

Hunkered Down for the Duration
Staff member
Admin
#3
Subject: Re: Q: Software Release /Roque/Sanghavi
Date: Mon, 14 Jun 1999 08:33:04 -0600
From: ISO Standards Discussion

From: Jatin Sanghavi
Subject: Re: Q: Software Release /Roque/Sanghavi

I work for a company which has been ISO certified so I hope your questions will be answered well.

a) when do you release a software product
b) how do you classify test failures (minor, major, catasthropic?)

The Software product is released when there are no bugs but most of the software in the world have some minor bugs cause to err is human. Most of the software in the world have some minor bugs and to remove these bugs, patches are being released after the software product is lauched. These patches will have to be given to the customer free of cost, most of the companies put these patches on the website so that the customer can download it.

c) when there are bugs found during system (integration) test, do you still release the product?

As I have written above If the bugs are minor and will not put the customer and the company into any problems then there is no problem to launch it but in future this bugs have to be fixed for customer satisfication.

d) any reasons of not releasing a product to the customer?

If the software have major bugs and the customer is not satisfied with its performance then it is not advicable to release the product. The software can be tested by the software testing and quality department before release.

e) how do you track test failures?

The test failures must be recorded each time the person performs the test as per the stratergies laid down by the software testing and Quality department. These records can be on the computer or hand written by the testor and should be verified signed by his project lead/project manager after the bugs or error have been fixed by the programmer.

If you need any more clarification, please fell free to write to me.

Warm Regards

Jatin
 
Thread starter Similar threads Forum Replies Date
B How to handle Medical Device Emergency Software Releases Software Quality Assurance 4
K Software Device "Urgent" Releases? Software Change Control Process IEC 62304 - Medical Device Software Life Cycle Processes 9
Y UL 1998 Standard: software classes Software Quality Assurance 0
P Need a programmer for QVI's VMS software for optical inspection machine Inspection, Prints (Drawings), Testing, Sampling and Related Topics 0
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 2
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
I Form templates for software (iso9001) Document Control Systems, Procedures, Forms and Templates 0
H Software Interface Translation IVD Regulation EU Medical Device Regulations 0
C 8.5.1.1 Control of Equipment, Tools, and Software Programs - Questions about the extent of control of NC programs AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
T Do I need a qualified compiler for class B software? IEC 62304 - Medical Device Software Life Cycle Processes 3
S Manufacturing Execution Systems Software Costs Manufacturing and Related Processes 0
E 13485:2016, Sections 4.1.6, 7.5.6 and 7.6 - Validation of Software - Need some Advice please ISO 13485:2016 - Medical Device Quality Management Systems 2
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
S HIPAA-compliant monitoring software (advice needed) Hospitals, Clinics & other Health Care Providers 0
A Software bug fixes after shipping a product EU Medical Device Regulations 3
J Medical software Patient outcome Medical Information Technology, Medical Software and Health Informatics 2
Y We are Looking for EASA LOA TYPE 1 experienced software developer Job Openings, Consulting and Employment Opportunities 0
F Grand Avenue Software, Q-Pulse or Qualio - which for a full eQMS? Medical Information Technology, Medical Software and Health Informatics 1
K SOUP (Software of Unknown Provenance) Anomaly Documentation IEC 62304 - Medical Device Software Life Cycle Processes 2
Q Storing and developing SAMD (Software as a Medical Device) in the Cloud IEC 62304 - Medical Device Software Life Cycle Processes 2
I Old Time Scatter diagrams for defect type and location- software Quality Tools, Improvement and Analysis 3
SocalSurfer AS9100 new certificate, but need QMS software, help Quality Assurance and Compliance Software Tools and Solutions 2
C Is my software an accessory? Telecommunication between HCP and patients EU Medical Device Regulations 10
K Verify Software Architecture - supporting interfaces between items IEC 62304 - Medical Device Software Life Cycle Processes 1
A What are the pros and cons of using an audit software for internal auditing? General Auditing Discussions 4
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
R Shall a new UDI-DI be required when stand-alone software device's version is updated? EU Medical Device Regulations 1
R MSA for ATE (Automatic Test Equipment Embedded Software) Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 9
S MDR GSPR Clause 17 - Software Requirements EU Medical Device Regulations 2
L Turkish Requirements - Does the Software need to be translated? CE Marking (Conformité Européene) / CB Scheme 2
MDD_QNA Medical Device Software - Is a Help Button required? IEC 62304 - Medical Device Software Life Cycle Processes 1
F Software as a Medical Device (SaMD) Technical File Requirements Manufacturing and Related Processes 1
D Software User Interface Languages for LVD and IVD CE Marking (Conformité Européene) / CB Scheme 2
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
K Software Validation for Measurement Tools used in Process Validation ISO 13485:2016 - Medical Device Quality Management Systems 2
B ISO 14971 Applied to Software ISO 14971 - Medical Device Risk Management 2
N ERP Software Implementation Manufacturing and Related Processes 3
C NCR (Nonconformance System) Software Nonconformance and Corrective Action 7
U Document Approval - Software company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
S SOP for ISO 13485:2016 Quality related Software validation ISO 13485:2016 - Medical Device Quality Management Systems 9
J Designing new gauge tracking software IATF 16949 - Automotive Quality Systems Standard 4
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 4
B Notified Bodies for Software (MDR) EU Medical Device Regulations 1
C MDR - Question around software accesories EU Medical Device Regulations 2
S Software for Supplier Charge back and internal PPM General Information Resources 2

Similar threads

Top Bottom