In theory, it seems to make sense, but as in many areas of life, common sense overcomes theory. In Level B and C there must be detailed, low-level software requirements and they must be thoroughly tested.
Remember, DOC requires detailed low level requirement verification beginning with Level C and those low level requirements will cover the vast majority of software logic decisions. Also, quality software engineering organizations already incorporate a semi-automated and streamlined process which includes independent reviews and tight configuration management; ergo the added cost of those aspects for Level B is largely mollified. The reader is well-advised to undergo upfront DO Training and DO Process Improvement to leverage these cost reduction techniques.
Such shortcuts enabled less detailed functional testing with many fewer logic branches verified. As a result of that greater detail, DOC inadvertently reduced the difference between Level C and Level B because the decision-condition structural coverage objective of Level B is largely covered already in Level C due to those more detailed low level requirements.
Level A is the most critical software level and hence the most expensive. Level A imposes yet more structural coverage requirements MCDC testing , source to binary correlation, and more independence within reviews.
However, with proper application of modern structural coverage tools, personnel training, and thorough requirements based testing, the added cost for Level A can be largely contained, thus Level A software is only slightly more expensive than Level B. DOC is certainly neither free nor cheap, as cited above.
However, DOC can actually be cost-effective, when implemented properly. Particularly when evaluated over a product lifetime or subsequent product versions when DOC efficiency and benefits are most notable.
Why then are so many entities adopting DO? Because of the actual DO benefits. Once acquired from AFuzion and customized on the first project, your DOC project will retain the expertise to create, customize and re-use as appropriate on future DOC projects. The Template form option provides the basic templates which you then modify to create an initial draft.
The regulatory agencies require that most airborne commercial systems operating within commercial airspace to comply with DOC and DO details can be found in the regulatory website. The planning and processes for the engineering lifecycle are required for any DOC and DO project and those processes must be defined before initiating that phase and followed during that phase.
Although Checklists are not formally required by DOC and DO, your regulatory agencies will require that you prove conformance to DOC and DO according to your approved processes; this conformance is very difficult to achieve and prove without checklists. AFuzion Process Templates are meant to provide the proper framework for customization to meet the system process requirements of DOC.
Although there is no perfect process for all programs, there are unique areas of each individual project. Each project will vary somewhat in how it chooses to define, implement, or augment the AFuzion process Templates. Further, AFuzion can customize and tailor these processes by the appropriate amount as an outflow of the gap analysis process, upon request as part of the optional first draft delivery. Independent reviews are always preferable to reviews done by the developer.
It should be noted that the checklists should be widely distributed to all personnel developing any avionics lifecycle item, prior to that person beginning such initiation.
This applies to requirements, design, implementation, test, etc. Usage of AFuzion process templates and checklists are intended to maximize the probability of project success and quality.
They were faced with a choice:. What choice was made? DOB identifies a number of software life cycle processes, with associated objectives, activities, and life cycle data:. A major emphasis of DOB is on software verification, which consists of reviews, analyses, and tests. Testing needs to be based on the software requirements, and coverage must be demonstrated in multiple senses:.
DOB places different demands on structural coverage based on the software level. The different DOB-levels are defined according to the possible consequences of a software error:. Catastrophic level A , hazardous-severe level B , major level C , minor level D or no-effect level E.
Flight control, navigation, and all fly-by-wire systems are flight critical and require DOB Level A certification. Blogroll carlodaffara. Powered by WordPress.
0コメント