QA Principles by James Hutchins
The verbs used in the standards and the priorities therein. The conduct of being impartially objective The perspective of not following illegal orders from a customer and giving workarounds. Corrective action objectives These are given with real-life happenings. Preemptively I would use a quote from the actor Sidney Poitier “words have (legal) meanings…”
Many products contracted today for and intended for delivery to customers are no longer just mechanical or are entirely software. A brief exploration of the lifecycles of both, how they interrelate could be explored or carried out in a follow on QA TechTalk Community discussion. Also, the modern emphasis on Mission Assurance vs potential delivery product failure is a topic.
Here are the two simplified diagrams I could use. The first is a simplified diagram showing the comparison of hardware development and software development with the classic reviews slicing vertically through both. The narrowing down from left to right is to emphasizes the increased precision necessary from the beginning to the final integrated product. The second … I know I will be jumping ahead … is the overall relationship of my QMS concept to SEI/CMMI and the major international quality standard ISO 9000 or it’s derivative follow ons (e.g. AS9100, ISO 9000/2000 and industrial adaptations).
Top-design Approach:
In general terms, it is a display of General major events for hardware on the top line and software on the bottom line as they relate in a pseudo timeline. The examiner should note the distance between the lines indicates only the width within the boundaries for both hardware and software individually in development and or assembly.
Also, after successful completion of the Formal Qualification Test the software is only qualified to the requirements…to get certified all the test documentation must — there I go again “must” — be analyzed and completed. Only then could it be considered certified with the combined report produced by Software Configuration Management.
Before presentation as a software deliverable — the software should be sealed … breaking that seal before the customer/end-user formally accepts it invalidates both its qualification and certification. Why, because its potential contamination can’t be verified.
References:
