The Elsmar Cove Wiki More Free Files The Elsmar Cove Forums Discussion Thread Index Post Attachments Listing Failure Modes Services and Solutions to Problems Elsmar cove Forums Main Page Elsmar Cove Home Page
Google
  Web Elsmar.com
*Please be aware that SOME RECENT forum threads may not yet be indexed by Google.

View Full Version : IT Software Life Cycle Development - How do 7.3.2 to 7.3.4 apply?


HPLJJ
29th October 2006, 09:36 PM
I'm new to this fantastic forum and have done some searching but couldn't find any reference to my problem - so, sorry if it has been covered before.

My company develops IT software. We have a fairly standard development life-cycle with design and development phases being as follows:
1. requirements design/document and review,
2. software design/document and review, and
3. code development and review

I am unsure as to how these equate to the clauses 7.3.2 (input), 7.3.3 (outputs) and 7.3.4 (review) as all 3 have inputs, outputs and reviews.

Jane

Sidney Vianna
29th October 2006, 10:21 PM
I'm new to this fantastic forum and have done some searching but couldn't find any reference to my problem - so, sorry if it has been covered before.

My company develops IT software. We have a fairly standard development life-cycle with design and development phases being as follows:
1. requirements design/document and review,
2. software design/document and review, and
3. code development and review

I am unsure as to how these equate to the clauses 7.3.2 (input), 7.3.3 (outputs) and 7.3.4 (review) as all 3 have inputs, outputs and reviews.

JaneThose would be phases of the product development. Phase 1 output will be part of phase 2 input and so on and so forth. Suggest you get a copy of ISO/IEC 90003 Guidelines to the application of ISO 9001 to computer software.

harry
29th October 2006, 10:28 PM
Would the following, extracted from ISO IEC 90003 be of help to you?

7.3.2 Define software design and development inputs.

* Specify product design and development inputs.

* Record product design and development input definitions

* Evaluate product design and development input definitions.

* Review input definitions before you approve them.

* Derive software design and development inputs.

* Derive software design and development
inputs from functional requirements.

* Derive software design and development
inputs from performance requirements.

* Derive software design and development
inputs from quality requirements.

* Derive software design and development
inputs from safety requirements.

* Derive software design and development
inputs from security requirements.


7.3.3 Generate software design and development outputs.

* Create software product design and development outputs.

* Approve software design and development outputs prior to release.

* Use design and development outputs to control software product quality. *
* Maintain a record of your software design and development outputs.


7.3.4 Carry out software design and development reviews.

* Carry out reviews throughout your software
product design and development process.

* Establish procedures that specify how problems identified during
your software design and development reviews should be handled.

* Establish procedures that specify how product
deficiencies or nonconformities should be handled.

* Establish procedures that specify how process
deficiencies or nonconformities should be handled.

* Formulate the guidelines that all participants will be expected
to follow during your software design and development reviews.


Regards.

HPLJJ
29th October 2006, 10:29 PM
I agree with what you are saying re Phase 1 output will be part of phase 2 input etc.

I am trying to map our development/build process to the ISO 9001 clauses under 7.3 Design and Development considering it is a phased process.

HPLJJ
29th October 2006, 10:37 PM
I have an extract of the iso/iec 90003 for these clauses but I still have my question.

Does clause 7.3.2 cover our Inputs for
- Requirements phase
- Software Design phase, and
- Coding

and the same for 7.3.3 and 7.3.4 because they all have inputs, outputs and reviews

tks,
Jane

harry
29th October 2006, 10:55 PM
Reviews are basically improvement process (and checks made to ensure all inputs and other requirements are taken care of) and whenever there are reviews/changes there will be new inputs and outputs. And they should be carried out at every stage of design and development.

Even at the 'beta' stage, there can be reviews (and therefore new input/output) as bugs etc are detected.

Regards.