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
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 3
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 8
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) 1
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
G Assignable cause/corrective action list for SPC Software Statistical Analysis Tools, Techniques and SPC 3
K ERP System Software Validation - ISO13485 2016 4.1.6 Design and Development of Products and Processes 8
S Recommendation for user friendly Gaga R&R and Cpk software Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 10
M HR (Human Resources) based software recommendations Human Factors and Ergonomics in Engineering 2
V Gage Management and Gage R&R Software General Measurement Device and Calibration Topics 1
F Medical Devices-South Africa _Post approval changes and Software Other Medical Device Regulations World-Wide 0
Marc Security in Health Industry Software - February 2020 IEC 27001 - Information Security Management Systems (ISMS) 0
D Software validation in Medical Equipment Other Medical Device and Orthopedic Related Topics 20
C Experience with Agile PLM (Product Lifecycle Management Software) software from Oracle? Document Control Systems, Procedures, Forms and Templates 3
JoCam Software Translation under MDR requirements EU Medical Device Regulations 5
W Air Quality Measurement Hardware and Software General Measurement Device and Calibration Topics 11
Q Is that any difficulty to do software DFMEA and PFMEA in ISO 13485? ISO 13485:2016 - Medical Device Quality Management Systems 5
F Management of Software version while NB reviews Technical file CE Marking (Conformité Européene) / CB Scheme 7
C QMS Document Management Software Recommendations Quality Assurance and Compliance Software Tools and Solutions 15
Q Software SOP - Use and maintenance of an ERP system Software Quality Assurance 4
Z Software Library - could it be a medical device? ISO 13485:2016 - Medical Device Quality Management Systems 5
B HIGH QA Software - Auto ballooning software Quality Assurance and Compliance Software Tools and Solutions 2
E In need of a new TGA sponsor - Small software company Other Medical Device Regulations World-Wide 4
I Custom software services to be used by medical software ISO 13485:2016 - Medical Device Quality Management Systems 1
S Examples of software changes that required a 510k US Food and Drug Administration (FDA) 2
S Best software for customer support/complaints? Customer Complaints 0
D Reduction of software class based on multiple external risk controls IEC 62304 - Medical Device Software Life Cycle Processes 5
M Informational TGA – Submissions received: Regulation of software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 1
B Does EN ISO 15223-1:2016 include the graphic symbols to be added to software and IFU? Other Medical Device Related Standards 9
G Strategy for IEC62304 implementation half way into the software development process IEC 62304 - Medical Device Software Life Cycle Processes 9
F Software development plan for SW update IEC 62304 - Medical Device Software Life Cycle Processes 2
D Requirements for the dimensions / color of medical device labels - Software as a Medical Device IEC 62304 - Medical Device Software Life Cycle Processes 2
T Electronic ECO/ECR Process - Software recommendations Document Control Systems, Procedures, Forms and Templates 3
B We need a QMS: file-based templates or software Other Medical Device Related Standards 23
C Looking for simple Software Validation IQ templates. Qualification and Validation (including 21 CFR Part 11) 4
M Informational EU – Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR Medical Device and FDA Regulations and Standards News 2
dgrainger Informational MDCG 2019-11: Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR Medical Device and FDA Regulations and Standards News 0
H QMS Software Recommendation (US based, Hemp) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
D Software as an accessory to a Class I medical device EU Medical Device Regulations 4
Similar threads


















































Top Bottom