This document discusses the definition of a "decision" when applying Modified Condition/Decision Coverage (MC/DC) and Decision Coverage (DC). There is confusion in the industry about whether a decision only refers to branch points or includes any Boolean expression. The certification authorities take the position that the literal definition from DO-178B/ED-12B should be followed, which is that a decision can include Boolean expressions outside of branch points. Applying the definition only to branch points could significantly weaken verification for safety-critical software. Alternative interpretations may be considered but require approval from the certification authority.
MC/DC testing requires focusing test cases on each condition individually to cover all possible outcomes of that condition, which can be done with fewer test cases than full pairwise testing. It works by fixing all other conditions while toggling the focused condition, resulting in test cases that ensure each condition alone can correctly affect the final decision. When all individual condition test cases are combined, the total number of test cases is less than that required for pairwise testing, providing coverage with fewer tests.
The document discusses the characteristics of a good Software Requirements Specification (SRS). It defines an SRS as a formal report that represents the software requirements and enables customers to review them. An SRS should be consistent with no conflicting requirements, unambiguous with only one interpretation per requirement, and ranked by importance and stability. It should also be modifiable, verifiable, traceable, design independent, testable, understandable by customers, and at the right level of abstraction.
The document discusses Open-DO, an open source initiative for developing safety-critical software. It provides an overview of Open-DO concepts like FLOSS, agile development practices, and high-integrity certification. Updates on Open-DO include new community projects, conferences, and tools to support qualifications. Formal methods like Couverture and Hi-Lite are presented as ways to verify properties and generate verification conditions for proof.
The document is a student assignment submission for a finance course. It includes the student number, confirmation that the work is original and plagiarized work will be subject to sanctions. It also notes the assignment details including the course code, title, section, and instructor. The student checks a box to confirm they have read and agree to the statements before providing their student number for submission.
The assignment itself involves analyzing two capital budgeting projects for a doll company - an extension of an existing doll clothing line and the launch of a new customizable doll product. It asks the student to discuss a potentially problematic aspect of the company's capital budgeting process, request additional information needed to evaluate one of the projects, and note an important consideration
JNR NON-PERMANENCE RISK REPORT VCS Version 3VCS JNR Non-Per.docxdonnajames55
JNR NON-PERMANENCE RISK REPORT: VCS Version 3
VCS JNR Non-Permanence Risk Report Template
This report template is for analyzing the non-permanence risk of VCS jurisdictional REDD+ programs. VCS projects, including nested projects, must use the VCS Non-Permanence Risk Report Template.
Instructions for completing the JNR Non-Permanence Risk Report:
TITLE PAGE: All items in the box at the bottom of the title page must be completed using Arial 10pt, black, regular (non-italic) font. This box must appear on the title page of the final document. The JNR non-permanence risk report may also feature the report title and preparer’s name and logo more prominently on the title page, using the format below (Arial 24pt and Arial 11pt, black, regular font).
JNR NON-PERMANENCE RISK REPORT: Instructions for completing the JNR non-permanence risk report can be found under the section headings in this template. All instructions must be followed. Instructions relate back to the rules and requirements set out in the JNR Requirements, VCS Standard and accompanying program documents. As such, this template must be completed in accordance with such documents, and the preparer will need to refer to the VCS program documents and in order to complete the template. It is also expected that relevant guidance is followed. Note that the instructions in this template are intended to serve as a guide and do not necessarily represent an exhaustive list of the information the preparer should provide under each section of the template.
All sections must be completed using Arial 10pt, black, regular (non-italic) font. Where a section is not applicable, same must be stated under the section (the section must not be deleted from the final document).
This document may be included as an annex to the JNR program description or JNR monitoring report, as applicable, or provided as a stand-alone document. Where submitted as an annex, the cover page may be deleted and where submitting as a stand-alone document, the cover page must be completed.
Where a jurisdiction is stratified due to different risk profiles, the whole document must be filled out for each area (either as separate documents, or by repeating all of the steps/tables).
All instructions, including this introductory text, should be deleted from the final document.
JNR NON-PERMANENCE RISK REPORT TITLE
Logo (optional)
Document Prepared By (individual or entity)
Jurisdictional REDD+ Program Title
Name of jurisdictional REDD+ program
Version
Version number of this document
Date of Issue
DD-Month-YYYY this version of the document issued
Program ID
VCS project database ID, if registered
Monitoring Period
DD-Month-YYYY to DD-Month-YYYY
Prepared By
Individual or entity that prepared the document
Contact
Physical address, telephone, email, website
Document and substantiate the risk and/or mitigation for each risk factor applicable to the jurisdictional program. Include any relevant documentary evidence. Where a risk or.
JNR NON-PERMANENCE RISK REPORT VCS Version 3VCS JNR Non-Per.docxvrickens
JNR NON-PERMANENCE RISK REPORT: VCS Version 3
VCS JNR Non-Permanence Risk Report Template
This report template is for analyzing the non-permanence risk of VCS jurisdictional REDD+ programs. VCS projects, including nested projects, must use the VCS Non-Permanence Risk Report Template.
Instructions for completing the JNR Non-Permanence Risk Report:
TITLE PAGE: All items in the box at the bottom of the title page must be completed using Arial 10pt, black, regular (non-italic) font. This box must appear on the title page of the final document. The JNR non-permanence risk report may also feature the report title and preparer’s name and logo more prominently on the title page, using the format below (Arial 24pt and Arial 11pt, black, regular font).
JNR NON-PERMANENCE RISK REPORT: Instructions for completing the JNR non-permanence risk report can be found under the section headings in this template. All instructions must be followed. Instructions relate back to the rules and requirements set out in the JNR Requirements, VCS Standard and accompanying program documents. As such, this template must be completed in accordance with such documents, and the preparer will need to refer to the VCS program documents and in order to complete the template. It is also expected that relevant guidance is followed. Note that the instructions in this template are intended to serve as a guide and do not necessarily represent an exhaustive list of the information the preparer should provide under each section of the template.
All sections must be completed using Arial 10pt, black, regular (non-italic) font. Where a section is not applicable, same must be stated under the section (the section must not be deleted from the final document).
This document may be included as an annex to the JNR program description or JNR monitoring report, as applicable, or provided as a stand-alone document. Where submitted as an annex, the cover page may be deleted and where submitting as a stand-alone document, the cover page must be completed.
Where a jurisdiction is stratified due to different risk profiles, the whole document must be filled out for each area (either as separate documents, or by repeating all of the steps/tables).
All instructions, including this introductory text, should be deleted from the final document.
JNR NON-PERMANENCE RISK REPORT TITLE
Logo (optional)
Document Prepared By (individual or entity)
Jurisdictional REDD+ Program Title
Name of jurisdictional REDD+ program
Version
Version number of this document
Date of Issue
DD-Month-YYYY this version of the document issued
Program ID
VCS project database ID, if registered
Monitoring Period
DD-Month-YYYY to DD-Month-YYYY
Prepared By
Individual or entity that prepared the document
Contact
Physical address, telephone, email, website
Document and substantiate the risk and/or mitigation for each risk factor applicable to the jurisdictional program. Include any relevant documentary evidence. Where a risk or ...
This document discusses the DCMA 14-Point Schedule Assessment protocol used to review federal contract schedules. It provides background on the DCMA and describes each of the 14 assessment checks. While the goal of increasing schedule rigor is valid, the author questions whether some checks like banning negative lags or requiring over 90% finish-to-start relationships are sufficiently supported. Implementing the checks too rigidly could open the government to claims rather than improving communication as intended.
MC/DC testing requires focusing test cases on each condition individually to cover all possible outcomes of that condition, which can be done with fewer test cases than full pairwise testing. It works by fixing all other conditions while toggling the focused condition, resulting in test cases that ensure each condition alone can correctly affect the final decision. When all individual condition test cases are combined, the total number of test cases is less than that required for pairwise testing, providing coverage with fewer tests.
The document discusses the characteristics of a good Software Requirements Specification (SRS). It defines an SRS as a formal report that represents the software requirements and enables customers to review them. An SRS should be consistent with no conflicting requirements, unambiguous with only one interpretation per requirement, and ranked by importance and stability. It should also be modifiable, verifiable, traceable, design independent, testable, understandable by customers, and at the right level of abstraction.
The document discusses Open-DO, an open source initiative for developing safety-critical software. It provides an overview of Open-DO concepts like FLOSS, agile development practices, and high-integrity certification. Updates on Open-DO include new community projects, conferences, and tools to support qualifications. Formal methods like Couverture and Hi-Lite are presented as ways to verify properties and generate verification conditions for proof.
The document is a student assignment submission for a finance course. It includes the student number, confirmation that the work is original and plagiarized work will be subject to sanctions. It also notes the assignment details including the course code, title, section, and instructor. The student checks a box to confirm they have read and agree to the statements before providing their student number for submission.
The assignment itself involves analyzing two capital budgeting projects for a doll company - an extension of an existing doll clothing line and the launch of a new customizable doll product. It asks the student to discuss a potentially problematic aspect of the company's capital budgeting process, request additional information needed to evaluate one of the projects, and note an important consideration
JNR NON-PERMANENCE RISK REPORT VCS Version 3VCS JNR Non-Per.docxdonnajames55
JNR NON-PERMANENCE RISK REPORT: VCS Version 3
VCS JNR Non-Permanence Risk Report Template
This report template is for analyzing the non-permanence risk of VCS jurisdictional REDD+ programs. VCS projects, including nested projects, must use the VCS Non-Permanence Risk Report Template.
Instructions for completing the JNR Non-Permanence Risk Report:
TITLE PAGE: All items in the box at the bottom of the title page must be completed using Arial 10pt, black, regular (non-italic) font. This box must appear on the title page of the final document. The JNR non-permanence risk report may also feature the report title and preparer’s name and logo more prominently on the title page, using the format below (Arial 24pt and Arial 11pt, black, regular font).
JNR NON-PERMANENCE RISK REPORT: Instructions for completing the JNR non-permanence risk report can be found under the section headings in this template. All instructions must be followed. Instructions relate back to the rules and requirements set out in the JNR Requirements, VCS Standard and accompanying program documents. As such, this template must be completed in accordance with such documents, and the preparer will need to refer to the VCS program documents and in order to complete the template. It is also expected that relevant guidance is followed. Note that the instructions in this template are intended to serve as a guide and do not necessarily represent an exhaustive list of the information the preparer should provide under each section of the template.
All sections must be completed using Arial 10pt, black, regular (non-italic) font. Where a section is not applicable, same must be stated under the section (the section must not be deleted from the final document).
This document may be included as an annex to the JNR program description or JNR monitoring report, as applicable, or provided as a stand-alone document. Where submitted as an annex, the cover page may be deleted and where submitting as a stand-alone document, the cover page must be completed.
Where a jurisdiction is stratified due to different risk profiles, the whole document must be filled out for each area (either as separate documents, or by repeating all of the steps/tables).
All instructions, including this introductory text, should be deleted from the final document.
JNR NON-PERMANENCE RISK REPORT TITLE
Logo (optional)
Document Prepared By (individual or entity)
Jurisdictional REDD+ Program Title
Name of jurisdictional REDD+ program
Version
Version number of this document
Date of Issue
DD-Month-YYYY this version of the document issued
Program ID
VCS project database ID, if registered
Monitoring Period
DD-Month-YYYY to DD-Month-YYYY
Prepared By
Individual or entity that prepared the document
Contact
Physical address, telephone, email, website
Document and substantiate the risk and/or mitigation for each risk factor applicable to the jurisdictional program. Include any relevant documentary evidence. Where a risk or.
JNR NON-PERMANENCE RISK REPORT VCS Version 3VCS JNR Non-Per.docxvrickens
JNR NON-PERMANENCE RISK REPORT: VCS Version 3
VCS JNR Non-Permanence Risk Report Template
This report template is for analyzing the non-permanence risk of VCS jurisdictional REDD+ programs. VCS projects, including nested projects, must use the VCS Non-Permanence Risk Report Template.
Instructions for completing the JNR Non-Permanence Risk Report:
TITLE PAGE: All items in the box at the bottom of the title page must be completed using Arial 10pt, black, regular (non-italic) font. This box must appear on the title page of the final document. The JNR non-permanence risk report may also feature the report title and preparer’s name and logo more prominently on the title page, using the format below (Arial 24pt and Arial 11pt, black, regular font).
JNR NON-PERMANENCE RISK REPORT: Instructions for completing the JNR non-permanence risk report can be found under the section headings in this template. All instructions must be followed. Instructions relate back to the rules and requirements set out in the JNR Requirements, VCS Standard and accompanying program documents. As such, this template must be completed in accordance with such documents, and the preparer will need to refer to the VCS program documents and in order to complete the template. It is also expected that relevant guidance is followed. Note that the instructions in this template are intended to serve as a guide and do not necessarily represent an exhaustive list of the information the preparer should provide under each section of the template.
All sections must be completed using Arial 10pt, black, regular (non-italic) font. Where a section is not applicable, same must be stated under the section (the section must not be deleted from the final document).
This document may be included as an annex to the JNR program description or JNR monitoring report, as applicable, or provided as a stand-alone document. Where submitted as an annex, the cover page may be deleted and where submitting as a stand-alone document, the cover page must be completed.
Where a jurisdiction is stratified due to different risk profiles, the whole document must be filled out for each area (either as separate documents, or by repeating all of the steps/tables).
All instructions, including this introductory text, should be deleted from the final document.
JNR NON-PERMANENCE RISK REPORT TITLE
Logo (optional)
Document Prepared By (individual or entity)
Jurisdictional REDD+ Program Title
Name of jurisdictional REDD+ program
Version
Version number of this document
Date of Issue
DD-Month-YYYY this version of the document issued
Program ID
VCS project database ID, if registered
Monitoring Period
DD-Month-YYYY to DD-Month-YYYY
Prepared By
Individual or entity that prepared the document
Contact
Physical address, telephone, email, website
Document and substantiate the risk and/or mitigation for each risk factor applicable to the jurisdictional program. Include any relevant documentary evidence. Where a risk or ...
This document discusses the DCMA 14-Point Schedule Assessment protocol used to review federal contract schedules. It provides background on the DCMA and describes each of the 14 assessment checks. While the goal of increasing schedule rigor is valid, the author questions whether some checks like banning negative lags or requiring over 90% finish-to-start relationships are sufficiently supported. Implementing the checks too rigidly could open the government to claims rather than improving communication as intended.
The document discusses code coverage from the perspective of DO178B certification. It explains that testing of code coverage is essential for safety-critical software certification. It describes the five levels of software criticality in DO178B from Level A to E, with A being the highest. The level of testing required varies according to the software's criticality level, from no structural testing needed for Level D to modified condition/decision coverage required for Level A.
The document provides sample exam questions and answers for the Certified Software Quality Engineer (CSQE) exam. It contains 10 multiple choice questions about software quality topics like regression testing, requirements, stakeholder management, change impact analysis, metrics, risk identification, project budget variances, reproducible builds, and process audits. Each question is followed by an explanation of the correct answer referencing sections of the CSQE Handbook.
20810chapter Information Systems Sourcing .docxRAJU852744
208
10
chapter Information Systems
Sourcing
After 13 years, Kellwood, an American apparel maker, ended its soups!to!nuts IS outsourcing
arrangement with EDS . The primary focus of the original outsourcing contract was to integrate
12 individually acquired units with different systems into one system. Kellwood had been satis-
" ed enough with EDS ’ s performance to renegotiate the contract in 2002 and 2008, even though
at each renegotiation point, Kellwood had considered bringing the IS operations back in house,
or backsourcing. The 2008 contract iteration resulted in a more # exible $105 million contract that
EDS estimated would save Kellwood $2 million in the " rst year and $9 million over the remaining
contract years. But the situation at Kellwood had changed drastically. In 2008, Kellwood had been
purchased by Sun Capital Partners and taken private. The chief operating of" cer (COO), who was
facing a mountain of debt and possibly bankruptcy, wanted to consolidate and bring the operations
back in house to give some order to the current situation and reduce costs. Kellwood was suffering
from a lack of IS standardization as a result of its many acquisitions. The chief information of" cer
(CIO) recognized the importance of IS standardization and costs, but she was concerned that the
transition from outsourcing to insourcing would cause serious disruption to IS service levels and
project deadlines if it went poorly. Kellwood hired a third!party consultant to help it explore the
issues and decided that backsourcing would save money and respond to changes caused by both the
market and internal forces. Kellwood decided to backsource and started the process in late 2009. It
carefully planned for the transition, and the implementation went smoothly. By performing stream-
lined operations in house, it was able to report an impressive $3.6 million savings, or about 17% of
annual IS expenses after the " rst year. 1
The Kellwood case demonstrates a series of decisions made in relation to sourcing. Both the
decision to outsource IS operations and then to bring them back in house were based on a series of
This chapter is organized around decisions in the Sourcing Decision Cycle. The ! rst question
regarding information systems (IS) in the cycle relates to the decision to make (insource) or
buy (outsource) them. This chapter ’ s focus is on issues related to outsourcing whereas issues
related to insourcing are discussed in other chapters of this book. Discussed are the critical
decisions in the Sourcing Decision Cycle: how and where (cloud computing, onshoring,
offshoring). When the choice is offshoring, the next decision is where abroad (farshoring,
nearshoring, or captive centers). Explored next in this chapter is the ! nal decision in the
cycle, keep as is or change in which case the current arrangements are assessed and modi-
! cations are made to the outsourcing arrangem.
20810chapter Information Systems Sourcing .docxlorainedeserre
208
10
chapter Information Systems
Sourcing
After 13 years, Kellwood, an American apparel maker, ended its soups!to!nuts IS outsourcing
arrangement with EDS . The primary focus of the original outsourcing contract was to integrate
12 individually acquired units with different systems into one system. Kellwood had been satis-
" ed enough with EDS ’ s performance to renegotiate the contract in 2002 and 2008, even though
at each renegotiation point, Kellwood had considered bringing the IS operations back in house,
or backsourcing. The 2008 contract iteration resulted in a more # exible $105 million contract that
EDS estimated would save Kellwood $2 million in the " rst year and $9 million over the remaining
contract years. But the situation at Kellwood had changed drastically. In 2008, Kellwood had been
purchased by Sun Capital Partners and taken private. The chief operating of" cer (COO), who was
facing a mountain of debt and possibly bankruptcy, wanted to consolidate and bring the operations
back in house to give some order to the current situation and reduce costs. Kellwood was suffering
from a lack of IS standardization as a result of its many acquisitions. The chief information of" cer
(CIO) recognized the importance of IS standardization and costs, but she was concerned that the
transition from outsourcing to insourcing would cause serious disruption to IS service levels and
project deadlines if it went poorly. Kellwood hired a third!party consultant to help it explore the
issues and decided that backsourcing would save money and respond to changes caused by both the
market and internal forces. Kellwood decided to backsource and started the process in late 2009. It
carefully planned for the transition, and the implementation went smoothly. By performing stream-
lined operations in house, it was able to report an impressive $3.6 million savings, or about 17% of
annual IS expenses after the " rst year. 1
The Kellwood case demonstrates a series of decisions made in relation to sourcing. Both the
decision to outsource IS operations and then to bring them back in house were based on a series of
This chapter is organized around decisions in the Sourcing Decision Cycle. The ! rst question
regarding information systems (IS) in the cycle relates to the decision to make (insource) or
buy (outsource) them. This chapter ’ s focus is on issues related to outsourcing whereas issues
related to insourcing are discussed in other chapters of this book. Discussed are the critical
decisions in the Sourcing Decision Cycle: how and where (cloud computing, onshoring,
offshoring). When the choice is offshoring, the next decision is where abroad (farshoring,
nearshoring, or captive centers). Explored next in this chapter is the ! nal decision in the
cycle, keep as is or change in which case the current arrangements are assessed and modi-
! cations are made to the outsourcing arrangem ...
The document discusses ongoing efforts by the FAA and European authorities to streamline and harmonize certification guidance for safety-critical systems. It summarizes workshops held by the FAA from 2015-2016 that refined three proposed "overarching properties" for certification. A parallel European initiative called RESSAC is working to define evaluation criteria for evidence against the properties. The author notes that while there is agreement on the high-level properties, applying them harmoniously remains a challenge that will require clear evaluation criteria. Efforts are continuing with further FAA and RESSAC workshops through 2018 to define deliverables. The goal remains an FAA Advisory Circular, though European authorities' next steps are unclear.
The document discusses common conflicts and pains that can lead to delays in the drug registration process from a commercial point of view. It identifies several key challenges, including lacking a project plan, regulatory intelligence, and issues with CMC data for both drug substances and drug products. Specific problems are outlined, such as invalid certificates, missing documentation, and inconsistencies between dossier sections. Recommendations are provided on how to address these challenges to minimize timelines and cut costs in the registration process.
Cmgt 554 cmgt554 cmgt 554 forecasting and strategic planning -uopstudy.comULLPTT
This document summarizes a course on IT infrastructure (CMGT 554) that includes the following:
- A study guide link and information on the first week's video exercise and quiz questions about the importance of management information systems (MIS).
- Details on an assignment to analyze the current infrastructure of a plastics company called International Plastics, Inc. and provide an executive summary.
- Information for week 2 including a video on telecommunications and networking along with an assignment analyzing the company's current standards and protocols.
- An assignment for week 3 to update the company's network diagrams with infrastructure improvement recommendations.
- Details on a week 4 video about ethical issues in information systems and its accompanying quiz questions.
This document presents the JPL Institutional Coding Standard for C programming. It aims to improve safety and reliability of code by providing a single standard, rather than project-specific ones. The standard is influenced by MISRA-C and the "Power of Ten" rules. It defines six levels of compliance (LOC), from general language rules to specific MISRA compliance. The standard scope is flight software, focusing on rules that reduce failure risk, excluding process requirements. "Shall" rules must be followed while "should" rules allow deviations with justification. Compliance is preferably verified with tools for each LOC level and parts of large codebases.
Discussion Shared Practice The Triple Bottom LineIs the o.docxelinoraudley582231
Discussion: Shared Practice: The Triple Bottom Line
“Is the organization making a profit?” That is what most stakeholders think about when they look at the bottom line. Yet, an organization might be making a profit while dumping toxic waste into the environment, treating employees poorly, or failing to conserve resources. Nonfinancial performance measures such as these can be challenging to measure. The Triple Bottom Line (TBL) is a framework that incorporates nonfinancial factors in measuring the performance of an organization. In addition to assessing profitability, the TBL approach also assesses an organization’s social and ecological impact.
Today’s socially conscious executive thoroughly grasps the significance of the TBL in terms of organizational and cultural success. TBL, which is sometimes referred to as part of the broader term corporate social responsibility (CSR), is a measure of an organization’s financial health, environmental sustainability, and its furtherance of social justice. One question that can be used to assess if an organization is meeting TBL objectives is whether or not the human experience of all stakeholders is elevated due to its work.
To prepare for this Discussion, “Shared Practice: The Triple Bottom Line,” review the Learning Resources for this week and consider how the Triple Bottom Line is related to and affected by an organization’s performance. Reflect on the meaning of corporate social responsibility and how this might impact your role in promoting social change.
Post by Day 3, the following:
•Predict how the implementation of the Triple Bottom Line would affect your current or former organization’s performance. Be sure to include at least two short term consequences and at least two long term consequences of using the TBL measurement system.
•Provide an explanation of how you view the relationship between corporate profits and social responsibility.
•Describe how you (as an executive) plan to use some of the skills learned in this course to promote social change in your organization now and in the future.
Session 12: Final Exam
Print
Due December 19 at 12:00 AM
Starts Dec 12, 2016 12:00 AM
INFA 620 - NETWORK AND INTERNET SECURITY
Final Exam
This is an open-book individual exam. You may use any resources in addition to the textbook, but you should do it individually without collaborating with others. Questions should be answered in your own words. Use quotation marks if not using your own words, and do not forget to cite full reference.
Other Guidelines:
· You should submit your exam to your assignment folder in WT as an HTML, MS-Word or plain text. When using HTML or plain text, you can either use the window available to paste your work, or attach your file.
· Repeat the text of the question you have selected.
· Be the clearest and objective you can in all questions and be sure you are answering what is asked.
· Put your name in the exam.
The exam is due on Monday (12/19) 12:00 am.
PROBLE.
The document provides an overview of the Software Development Life Cycle (SDLC), including:
- The SDLC is a process consisting of planned activities to develop or alter software products. It aims to produce high-quality software that meets requirements.
- Common SDLC models include waterfall, iterative, spiral, V-model, big bang, agile, RAD, and prototyping. Each has distinct phases and approaches.
- The waterfall model is sequential with distinct phases like planning, design, implementation, testing, and deployment. It works well for small, stable projects but not for complex projects with changing requirements.
The document provides an overview of the Software Development Life Cycle (SDLC), including:
- The SDLC is a process consisting of planned activities to develop or alter software products. It aims to produce high-quality software that meets requirements.
- Common SDLC models include waterfall, iterative, spiral, V-model, big bang, agile, RAD, and prototyping. Each has distinct phases and approaches.
- The waterfall model is sequential with distinct phases like planning, design, implementation, testing, and deployment. It works well for small, stable projects but not for complex projects with changing requirements.
OpenChain Monthly Meeting 2023-02-21 (North America and Asia)Shane Coughlan
The document summarizes the agenda and discussions from an OpenChain monthly meeting on February 21, 2023. Key discussion points included:
- Reminders about anti-trust policies for the meeting.
- Updates on adoption of OpenChain specifications, security assurance certification programs, and free online training courses.
- Discussion of definitions in the specifications to harmonize licensing and security definitions.
- Proposed changes to the security assurance specification in response to issues raised on GitHub, including adding definitions for "remediate" and "mitigate", adding requirements under the "Competence" category, and including references to relevant ISO standards.
The document contains 20 multiple choice questions related to project management concepts and processes. The questions cover topics like investment decision making, quality metrics, project team directories, contract management, risk analysis, stakeholder management, and ethics. For each question, the correct multiple choice answer is provided along with a brief justification or reference.
This software test plan document provides details on testing for a software project called XXX. It describes the test environment, identification of planned tests, schedules, and traceability of requirements to tests. Tests are divided into phases and categories and will verify requirements from the software requirements specification document for XXX.
OpenChain Monthly Meeting North America - Europe - 2023-02-07Shane Coughlan
The OpenChain monthly meeting covered several topics:
1. An anti-trust policy notice reminding attendees to adhere to agendas and not participate in prohibited antitrust activities.
2. Specification news including recent adoption of security assurance specifications, a new third-party certifier, and updates to free online training courses.
3. Work on standards and core materials including proposed changes to open source definitions and discussions of issues raised on GitHub regarding adding new definitions, requirements, and references to ISO standards within the Security Assurance Specification.
Understanding DO-178: Importance and How It Affects Your CompanyAversan Inc.
Learn DO-178: Why is it important? How can it affect your company? These questions and more will be answered in this presentation, including information regarding the purpose of DO-178, Design Assurance Levels (DAL), objectives, and integral processes.
Questions? Email bd@aversan.com for more information.
DevOps for Highly Regulated EnvironmentsDevOps.com
Financial institutions, medical groups, governmental organizations, automotive companies… these types of entities all have unique and sometimes difficult-to-meet regulations. You may be required to have fine-grained auditability of your SDLC or maintain specific third-party integrations. Security models may be heightened, or certain types of compliance processes maintained. So how are we supposed to “do the DevOps” when we have so many things to worry about? In this webinar, we’ll explore some ways that you can adopt DevOps best practices and even (gasp!) thrive when building your DevOps and DevSecOps pipelines in highly-regulated industries.
SWE-401 - 4. Software Requirement Specifications ghayour abbas
The document defines a Software Requirements Specification (SRS) as a formal report that lays the foundation for software engineering activities by eliciting and analyzing all system requirements. An SRS should have several key characteristics, including being correct, complete, consistent, unambiguous, modifiable, verifiable, and traceable. It should also be structured, concise, written from a black-box perspective, demonstrate conceptual integrity, and contain requirements that can be verified. The purpose of an SRS is to formally represent the desired software system and allow customers to review that the system meets their needs.
The document discusses code coverage from the perspective of DO178B certification. It explains that testing of code coverage is essential for safety-critical software certification. It describes the five levels of software criticality in DO178B from Level A to E, with A being the highest. The level of testing required varies according to the software's criticality level, from no structural testing needed for Level D to modified condition/decision coverage required for Level A.
The document provides sample exam questions and answers for the Certified Software Quality Engineer (CSQE) exam. It contains 10 multiple choice questions about software quality topics like regression testing, requirements, stakeholder management, change impact analysis, metrics, risk identification, project budget variances, reproducible builds, and process audits. Each question is followed by an explanation of the correct answer referencing sections of the CSQE Handbook.
20810chapter Information Systems Sourcing .docxRAJU852744
208
10
chapter Information Systems
Sourcing
After 13 years, Kellwood, an American apparel maker, ended its soups!to!nuts IS outsourcing
arrangement with EDS . The primary focus of the original outsourcing contract was to integrate
12 individually acquired units with different systems into one system. Kellwood had been satis-
" ed enough with EDS ’ s performance to renegotiate the contract in 2002 and 2008, even though
at each renegotiation point, Kellwood had considered bringing the IS operations back in house,
or backsourcing. The 2008 contract iteration resulted in a more # exible $105 million contract that
EDS estimated would save Kellwood $2 million in the " rst year and $9 million over the remaining
contract years. But the situation at Kellwood had changed drastically. In 2008, Kellwood had been
purchased by Sun Capital Partners and taken private. The chief operating of" cer (COO), who was
facing a mountain of debt and possibly bankruptcy, wanted to consolidate and bring the operations
back in house to give some order to the current situation and reduce costs. Kellwood was suffering
from a lack of IS standardization as a result of its many acquisitions. The chief information of" cer
(CIO) recognized the importance of IS standardization and costs, but she was concerned that the
transition from outsourcing to insourcing would cause serious disruption to IS service levels and
project deadlines if it went poorly. Kellwood hired a third!party consultant to help it explore the
issues and decided that backsourcing would save money and respond to changes caused by both the
market and internal forces. Kellwood decided to backsource and started the process in late 2009. It
carefully planned for the transition, and the implementation went smoothly. By performing stream-
lined operations in house, it was able to report an impressive $3.6 million savings, or about 17% of
annual IS expenses after the " rst year. 1
The Kellwood case demonstrates a series of decisions made in relation to sourcing. Both the
decision to outsource IS operations and then to bring them back in house were based on a series of
This chapter is organized around decisions in the Sourcing Decision Cycle. The ! rst question
regarding information systems (IS) in the cycle relates to the decision to make (insource) or
buy (outsource) them. This chapter ’ s focus is on issues related to outsourcing whereas issues
related to insourcing are discussed in other chapters of this book. Discussed are the critical
decisions in the Sourcing Decision Cycle: how and where (cloud computing, onshoring,
offshoring). When the choice is offshoring, the next decision is where abroad (farshoring,
nearshoring, or captive centers). Explored next in this chapter is the ! nal decision in the
cycle, keep as is or change in which case the current arrangements are assessed and modi-
! cations are made to the outsourcing arrangem.
20810chapter Information Systems Sourcing .docxlorainedeserre
208
10
chapter Information Systems
Sourcing
After 13 years, Kellwood, an American apparel maker, ended its soups!to!nuts IS outsourcing
arrangement with EDS . The primary focus of the original outsourcing contract was to integrate
12 individually acquired units with different systems into one system. Kellwood had been satis-
" ed enough with EDS ’ s performance to renegotiate the contract in 2002 and 2008, even though
at each renegotiation point, Kellwood had considered bringing the IS operations back in house,
or backsourcing. The 2008 contract iteration resulted in a more # exible $105 million contract that
EDS estimated would save Kellwood $2 million in the " rst year and $9 million over the remaining
contract years. But the situation at Kellwood had changed drastically. In 2008, Kellwood had been
purchased by Sun Capital Partners and taken private. The chief operating of" cer (COO), who was
facing a mountain of debt and possibly bankruptcy, wanted to consolidate and bring the operations
back in house to give some order to the current situation and reduce costs. Kellwood was suffering
from a lack of IS standardization as a result of its many acquisitions. The chief information of" cer
(CIO) recognized the importance of IS standardization and costs, but she was concerned that the
transition from outsourcing to insourcing would cause serious disruption to IS service levels and
project deadlines if it went poorly. Kellwood hired a third!party consultant to help it explore the
issues and decided that backsourcing would save money and respond to changes caused by both the
market and internal forces. Kellwood decided to backsource and started the process in late 2009. It
carefully planned for the transition, and the implementation went smoothly. By performing stream-
lined operations in house, it was able to report an impressive $3.6 million savings, or about 17% of
annual IS expenses after the " rst year. 1
The Kellwood case demonstrates a series of decisions made in relation to sourcing. Both the
decision to outsource IS operations and then to bring them back in house were based on a series of
This chapter is organized around decisions in the Sourcing Decision Cycle. The ! rst question
regarding information systems (IS) in the cycle relates to the decision to make (insource) or
buy (outsource) them. This chapter ’ s focus is on issues related to outsourcing whereas issues
related to insourcing are discussed in other chapters of this book. Discussed are the critical
decisions in the Sourcing Decision Cycle: how and where (cloud computing, onshoring,
offshoring). When the choice is offshoring, the next decision is where abroad (farshoring,
nearshoring, or captive centers). Explored next in this chapter is the ! nal decision in the
cycle, keep as is or change in which case the current arrangements are assessed and modi-
! cations are made to the outsourcing arrangem ...
The document discusses ongoing efforts by the FAA and European authorities to streamline and harmonize certification guidance for safety-critical systems. It summarizes workshops held by the FAA from 2015-2016 that refined three proposed "overarching properties" for certification. A parallel European initiative called RESSAC is working to define evaluation criteria for evidence against the properties. The author notes that while there is agreement on the high-level properties, applying them harmoniously remains a challenge that will require clear evaluation criteria. Efforts are continuing with further FAA and RESSAC workshops through 2018 to define deliverables. The goal remains an FAA Advisory Circular, though European authorities' next steps are unclear.
The document discusses common conflicts and pains that can lead to delays in the drug registration process from a commercial point of view. It identifies several key challenges, including lacking a project plan, regulatory intelligence, and issues with CMC data for both drug substances and drug products. Specific problems are outlined, such as invalid certificates, missing documentation, and inconsistencies between dossier sections. Recommendations are provided on how to address these challenges to minimize timelines and cut costs in the registration process.
Cmgt 554 cmgt554 cmgt 554 forecasting and strategic planning -uopstudy.comULLPTT
This document summarizes a course on IT infrastructure (CMGT 554) that includes the following:
- A study guide link and information on the first week's video exercise and quiz questions about the importance of management information systems (MIS).
- Details on an assignment to analyze the current infrastructure of a plastics company called International Plastics, Inc. and provide an executive summary.
- Information for week 2 including a video on telecommunications and networking along with an assignment analyzing the company's current standards and protocols.
- An assignment for week 3 to update the company's network diagrams with infrastructure improvement recommendations.
- Details on a week 4 video about ethical issues in information systems and its accompanying quiz questions.
This document presents the JPL Institutional Coding Standard for C programming. It aims to improve safety and reliability of code by providing a single standard, rather than project-specific ones. The standard is influenced by MISRA-C and the "Power of Ten" rules. It defines six levels of compliance (LOC), from general language rules to specific MISRA compliance. The standard scope is flight software, focusing on rules that reduce failure risk, excluding process requirements. "Shall" rules must be followed while "should" rules allow deviations with justification. Compliance is preferably verified with tools for each LOC level and parts of large codebases.
Discussion Shared Practice The Triple Bottom LineIs the o.docxelinoraudley582231
Discussion: Shared Practice: The Triple Bottom Line
“Is the organization making a profit?” That is what most stakeholders think about when they look at the bottom line. Yet, an organization might be making a profit while dumping toxic waste into the environment, treating employees poorly, or failing to conserve resources. Nonfinancial performance measures such as these can be challenging to measure. The Triple Bottom Line (TBL) is a framework that incorporates nonfinancial factors in measuring the performance of an organization. In addition to assessing profitability, the TBL approach also assesses an organization’s social and ecological impact.
Today’s socially conscious executive thoroughly grasps the significance of the TBL in terms of organizational and cultural success. TBL, which is sometimes referred to as part of the broader term corporate social responsibility (CSR), is a measure of an organization’s financial health, environmental sustainability, and its furtherance of social justice. One question that can be used to assess if an organization is meeting TBL objectives is whether or not the human experience of all stakeholders is elevated due to its work.
To prepare for this Discussion, “Shared Practice: The Triple Bottom Line,” review the Learning Resources for this week and consider how the Triple Bottom Line is related to and affected by an organization’s performance. Reflect on the meaning of corporate social responsibility and how this might impact your role in promoting social change.
Post by Day 3, the following:
•Predict how the implementation of the Triple Bottom Line would affect your current or former organization’s performance. Be sure to include at least two short term consequences and at least two long term consequences of using the TBL measurement system.
•Provide an explanation of how you view the relationship between corporate profits and social responsibility.
•Describe how you (as an executive) plan to use some of the skills learned in this course to promote social change in your organization now and in the future.
Session 12: Final Exam
Print
Due December 19 at 12:00 AM
Starts Dec 12, 2016 12:00 AM
INFA 620 - NETWORK AND INTERNET SECURITY
Final Exam
This is an open-book individual exam. You may use any resources in addition to the textbook, but you should do it individually without collaborating with others. Questions should be answered in your own words. Use quotation marks if not using your own words, and do not forget to cite full reference.
Other Guidelines:
· You should submit your exam to your assignment folder in WT as an HTML, MS-Word or plain text. When using HTML or plain text, you can either use the window available to paste your work, or attach your file.
· Repeat the text of the question you have selected.
· Be the clearest and objective you can in all questions and be sure you are answering what is asked.
· Put your name in the exam.
The exam is due on Monday (12/19) 12:00 am.
PROBLE.
The document provides an overview of the Software Development Life Cycle (SDLC), including:
- The SDLC is a process consisting of planned activities to develop or alter software products. It aims to produce high-quality software that meets requirements.
- Common SDLC models include waterfall, iterative, spiral, V-model, big bang, agile, RAD, and prototyping. Each has distinct phases and approaches.
- The waterfall model is sequential with distinct phases like planning, design, implementation, testing, and deployment. It works well for small, stable projects but not for complex projects with changing requirements.
The document provides an overview of the Software Development Life Cycle (SDLC), including:
- The SDLC is a process consisting of planned activities to develop or alter software products. It aims to produce high-quality software that meets requirements.
- Common SDLC models include waterfall, iterative, spiral, V-model, big bang, agile, RAD, and prototyping. Each has distinct phases and approaches.
- The waterfall model is sequential with distinct phases like planning, design, implementation, testing, and deployment. It works well for small, stable projects but not for complex projects with changing requirements.
OpenChain Monthly Meeting 2023-02-21 (North America and Asia)Shane Coughlan
The document summarizes the agenda and discussions from an OpenChain monthly meeting on February 21, 2023. Key discussion points included:
- Reminders about anti-trust policies for the meeting.
- Updates on adoption of OpenChain specifications, security assurance certification programs, and free online training courses.
- Discussion of definitions in the specifications to harmonize licensing and security definitions.
- Proposed changes to the security assurance specification in response to issues raised on GitHub, including adding definitions for "remediate" and "mitigate", adding requirements under the "Competence" category, and including references to relevant ISO standards.
The document contains 20 multiple choice questions related to project management concepts and processes. The questions cover topics like investment decision making, quality metrics, project team directories, contract management, risk analysis, stakeholder management, and ethics. For each question, the correct multiple choice answer is provided along with a brief justification or reference.
This software test plan document provides details on testing for a software project called XXX. It describes the test environment, identification of planned tests, schedules, and traceability of requirements to tests. Tests are divided into phases and categories and will verify requirements from the software requirements specification document for XXX.
OpenChain Monthly Meeting North America - Europe - 2023-02-07Shane Coughlan
The OpenChain monthly meeting covered several topics:
1. An anti-trust policy notice reminding attendees to adhere to agendas and not participate in prohibited antitrust activities.
2. Specification news including recent adoption of security assurance specifications, a new third-party certifier, and updates to free online training courses.
3. Work on standards and core materials including proposed changes to open source definitions and discussions of issues raised on GitHub regarding adding new definitions, requirements, and references to ISO standards within the Security Assurance Specification.
Understanding DO-178: Importance and How It Affects Your CompanyAversan Inc.
Learn DO-178: Why is it important? How can it affect your company? These questions and more will be answered in this presentation, including information regarding the purpose of DO-178, Design Assurance Levels (DAL), objectives, and integral processes.
Questions? Email bd@aversan.com for more information.
DevOps for Highly Regulated EnvironmentsDevOps.com
Financial institutions, medical groups, governmental organizations, automotive companies… these types of entities all have unique and sometimes difficult-to-meet regulations. You may be required to have fine-grained auditability of your SDLC or maintain specific third-party integrations. Security models may be heightened, or certain types of compliance processes maintained. So how are we supposed to “do the DevOps” when we have so many things to worry about? In this webinar, we’ll explore some ways that you can adopt DevOps best practices and even (gasp!) thrive when building your DevOps and DevSecOps pipelines in highly-regulated industries.
SWE-401 - 4. Software Requirement Specifications ghayour abbas
The document defines a Software Requirements Specification (SRS) as a formal report that lays the foundation for software engineering activities by eliciting and analyzing all system requirements. An SRS should have several key characteristics, including being correct, complete, consistent, unambiguous, modifiable, verifiable, and traceable. It should also be structured, concise, written from a black-box perspective, demonstrate conceptual integrity, and contain requirements that can be verified. The purpose of an SRS is to formally represent the desired software system and allow customers to review that the system meets their needs.
1. Certification Authorities Software Team
(CAST)
Position Paper
CAST-10
What is a “Decision” in Application of Modified Condition/Decision
Coverage (MC/DC) and Decision Coverage (DC)?
Completed June 2002
NOTE: This position paper has been coordinated
among the software specialists of certification
authorities from the United States, Europe, and
Canada. However, it does not constitute official
policy or guidance from any of the authorities.
This document is provided for educational and
informational purposes only and should be
discussed with the appropriate certification
authority when considering for actual projects.
2. NOTE: This position paper has been coordinated among the software specialists of certification
authorities from the United States, Europe, and Canada. However, it does not constitute official
policy or guidance from any of the authorities. This document is provided for educational and
informational purposes only and should be discussed with the appropriate certification authority
when considering for actual projects.
1
What is a “Decision” in Application of Modified Condition/Decision
Coverage (MC/DC) and Decision Coverage (DC)?
Abstract:
The purpose of this paper is to present the certification authorities’ position of what a
decision is when applying Modified Condition/Decision Coverage (MC/DC) and
Decision Coverage (DC).
Key words:
Decision, decision coverage (DC), modified condition/decision coverage (MC/DC),
structural coverage, branch, branch point, code, code-control construct, condition, Boolean
expression
1 Purpose
The purpose of this paper is to present the certification authorities’ position of what a
decision is when applying Modified Condition/Decision Coverage (MC/DC) and
Decision Coverage (DC).
2 Background
There has been confusion regarding the definition of “decision” in DO-178B/ED-12B [1].
The definition affects the application of decision coverage (DC) for Levels B and A
software and modified condition/decision coverage (MC/DC) for Level A software.
DO-178B/ED-12B includes the following definitions [1]:
Condition - A Boolean expression containing no Boolean operators.
Decision - A Boolean expression composed of conditions and zero or
more Boolean operators. A decision without a Boolean operator is a
condition. If a condition appears more than once in a decision, each
occurrence is a distinct condition.
Decision Coverage - Every point of entry and exit in the program has
been invoked at least once and every decision in the program has taken
on all possible outcomes at least once.
Modified Condition/Decision Coverage - Every point of entry and exit in
the program has been invoked at least once, every condition in a decision
in the program has taken all possible outcomes at least once, every
decision in the program has taken all possible outcomes at least once,
and each condition in a decision has been shown to independently affect
3. NOTE: This position paper has been coordinated among the software specialists of certification
authorities from the United States, Europe, and Canada. However, it does not constitute official
policy or guidance from any of the authorities. This document is provided for educational and
informational purposes only and should be discussed with the appropriate certification authority
when considering for actual projects.
2
that decision's outcome. A condition is shown to independently affect a
decision's outcome by varying just that condition while holding fixed all
other possible conditions.
The confusion centers around the “traditional” industry understanding of “branch point”
(which is typically an if-then-else, do-while, or case statement) versus the DO-178B/ED-
12B literal definition of “decision.”
IEEE Std 100-1992, Standard Dictionary of Electrical and Electronic Terms, includes the
following relevant definitions, which illustrate the “traditional” industry terminology [2]:
• branch (1) (software). (A) A computer program construct in which one of two or
more alternative sets of programs statements is selected for execution. See also:
case; jump; go to; if-then-else. (B) A point in a computer program at which one
of two or more alternative sets of program statements is selected for execution.
Syn: branchpoint. (C) Any of the alternative sets of program statements in (A).
(D) To perform the selection in (A).” … (6) (electronic computer). (A) A set of
instructions that are executed between two successive decision instructions. (B)
To select a branch as in (A). (C) Loosely, a conditional jump. See conditional
jump.
• branch testing. Testing designed to execute each outcome of each decision point
in a computer program. Contrast with: path testing; statement testing.
• path testing. Testing designed to execute all or selected paths through a computer
program. Contrast with: branch testing; statement testing.
• control statement (software). A program statement that selects among alternative
sets of programs statements or affects the order in which operations are
performed. For example, if-then-else, case. Contrast with: assignment statement,
declaration.
In the creation of the MC/DC tutorial (a joint effort between NASA, FAA, and several
industry participants), this particular issue was discussed at a high level. The MC/DC
tutorial focuses specifically on MC/DC and states: “a decision is not synonymous with a
branch point. MC/DC applies to all decisions – not just those within a branch point”
([3], page 13). The tutorial was reviewed by several industry participants and SC-
190/WG-52 members and found to be satisfactory for MC/DC application.
Basically, for MC/DC, the tutorial indicates that a decision includes the traditional branch
points plus Boolean operations that appear in assignment statements, actual parameters,
indexers, aggregates, etc. For example, both assignment statements below contain
decisions, even though neither of the statements are branch points such as an “if”
statement (reference page 13 of the MC/DC tutorial):
A := B or C;
E := A and D;
4. NOTE: This position paper has been coordinated among the software specialists of certification
authorities from the United States, Europe, and Canada. However, it does not constitute official
policy or guidance from any of the authorities. This document is provided for educational and
informational purposes only and should be discussed with the appropriate certification authority
when considering for actual projects.
3
The MC/DC tutorial supports the “literal” definition of decision in DO-178B/ED-12B. It
should also be noted that DO-178B/ED-12B also asks for entry and exit point coverage,
which is also not part of the “traditional” branch coverage.
The following concepts illustrate the “literal” definition of decision [4].
1. Structural coverage guidelines are:
a) Every statement in the program has been invoked at least once;
b) Every point of entry and exit in the program has been invoked at least once;
c) Every control statement (i.e., branchpoint) in the program has taken all
possible outcomes (i.e., branches) at least once;
d) Every non-constant Boolean expression in the program has evaluated to
both a True and a False result;
e) Every non-constant condition in a Boolean expression in the program has
evaluated to both a True and a False result;
f) Every non-constant condition in a Boolean expression in the program has
been shown to independently affect that expression's outcome.
2. Based upon these definitions:
• Statement Coverage requires (a) only
• DC requires (b, c, d)
• MC/DC requires (b, c, d, e, f)
The issue is that at least some industry participants are not applying this “literal”
definition of decision. I.e., some industry participants are equating branch coverage and
decision coverage, leading to inconsistency in the interpretation and application of DC
and MC/DC in the industry. Tool manufacturers, in particular, tend to be inconsistent in
the approach, since many of them come from a “traditional” testing background (using
the IEEE definitions), rather than an aviation background.
There are a number of potential reasons for this inconsistency:
• Lack of clarification and training materials on DO-178B/ED-12B
• The difference from the aviation community and the traditional software testing
community
• Lack of agreement among the authors of DO-178B/ED-12B themselves
• Use of commercial verification tools that are developed outside the aviation
industry
There seems to be a variety of opinions about the definition of decision and coverage
requirements. Three common opinions prevail:
1) Some support the “literal” definition of DO-178B/ED-12B definition for
decision coverage (i.e., a decision is more than a branch point). The DO-178B
“literal” definition of decision is: A Boolean expression composed of
conditions and zero or more Boolean operators. A decision without a
5. NOTE: This position paper has been coordinated among the software specialists of certification
authorities from the United States, Europe, and Canada. However, it does not constitute official
policy or guidance from any of the authorities. This document is provided for educational and
informational purposes only and should be discussed with the appropriate certification authority
when considering for actual projects.
4
Boolean operator is a condition. If a condition appears more than once in a
decision, each occurrence is a distinct condition.
2) Some believe that the “intended” definition of DO-178B/ED-12B is different
than the “literal” definition (i.e., branch coverage is equal to decision
coverage).
3) Some apply the “literal” definition of decision for MC/DC and the “relaxed”
definition for DC. See the following section for examples of this “relaxed”
decision coverage interpretation.
There is variance in the interpretation of the meaning of decision, even among those who
were on the joint RTCA/EUROCAE committee that produced DO-178B/ED-12B.
3 An Example To Illustrate the Dilemma
Consider the following code in order to illustrate the difference between “branch point”
and DO-178B/ED-12B’s definition of “decision”:
A := B or C;
E := A and D;
if E then …
3.1 For the “literal” definition of decision for MC/DC, all of the following must
be shown:
• A has been assigned both True and False (item “d” from section 2 guidelines
above);
• B has the correct independent effect on A (items “e” and “f” from section 2
guidelines above);
• C has the correct independent effect on A (items “e” and “f” from section 2
guidelines above);
• E has been assigned both True and False (item “e” from section 2 guidelines
above);
• A has the correct independent effect on E (item “f” from section 2 guidelines
above);
• D has the correct independent effect on E (items “e” and “f” from section 2
guidelines above); and
• E has the correct independent effect on the if-then statement (i.e., E has been
both True and False, and the if-then statement has branched True and False
accordingly) (item “c” from section 2 guidelines above).
This applies whether the assignments (Boolean expressions) are contained in the same
code component as the if-then statement, or in a different code component. This
6. NOTE: This position paper has been coordinated among the software specialists of certification
authorities from the United States, Europe, and Canada. However, it does not constitute official
policy or guidance from any of the authorities. This document is provided for educational and
informational purposes only and should be discussed with the appropriate certification authority
when considering for actual projects.
5
illustrates one of the major benefits of the “literal” definition for MC/DC: no matter
how the logic is distributed across the system’s computer program and modules,
MC/DC will address it.
3.2 If “branch point” equals “decision” for MC/DC, it must be shown that:
• E has the correct independent effect on the if-statement (i.e., E has been both
True and False, and the if-statement has branched True and False accordingly)
(item “c” from section 2 guidelines above).
This interpretation allows significantly weaker verification to be performed on logic. In
fact, one can now write code using temporaries for logic so that there would be no
difference between DC and MC/DC.
3.3 For the “literal” definition of decision for DC, it must be shown that:
• A has been assigned both True and False (item “d” from section 2 guidelines
above);
• E has been assigned both True and False (item “d” from section 2 guidelines
above); and
• E has the correct independent effect on the if-statement (i.e., E has been both
True and False, and the if-statement has branched True and False accordingly)
(item “c” from section 2 guidelines above).
The third coverage guideline subsumes the second; therefore, there are two essential
coverage guidelines for DC with the literal definition. Note that if the three statements
are in the same component, the third coverage guideline ensures that A has been assigned
a True value, satisfying half of the first coverage requirement. If the three statements are
distributed across different components, then this may no longer be true unless the
coverage analysis is performed with integrated components, rather than stand-alone
components.
3.4 If “branch point” equals “decision” for DC, it must be shown that:
• E has the correct effect on the if-statement (i.e., E has been both True and
False, and the if-statement has branched True and False accordingly) (item “c”
from section 2 guidelines above).
This interpretation allows weaker verification to be performed on logic. The weakening
is proportional to the number of Boolean expressions flowing into the branch point (i.e.,
no weakening if a single expression of atomic values flows into the branch point), how
many components the expressions are distributed across, and whether coverage analysis
is performed with fully integrated components or stand-alone components.
7. NOTE: This position paper has been coordinated among the software specialists of certification
authorities from the United States, Europe, and Canada. However, it does not constitute official
policy or guidance from any of the authorities. This document is provided for educational and
informational purposes only and should be discussed with the appropriate certification authority
when considering for actual projects.
6
4 Certification Authorities’ Position on the “Literal” Definition of Decision
The certification authorities recommend the "literal" definition of decision for DC and
MC/DC. The logic and control structure in Levels A and B software must be thoroughly
exercised, whether it occurs at a branch point or not. To equate decision and branch point
could allow Levels A and B software to be coded with all Boolean expressions outside of
the components’ code-control constructs (e.g., with all Boolean operators in assignment
and declaration statements, possible in a data component or package, which is not
considered to be a functional component, and therefore, may be considered exempt from
the structural coverage criteria). This could significantly weaken the verification effort
and test coverage achieved. This is clearly not acceptable to satisfy the objectives of DO-
178B/ED-12B.
5 Certification Authorities’ Position on Alternatives to The Literal Definition
DO-178B/ED-12B is recognized by Advisory Circular 20-115B and Temporary
Guidance Leaflet #4 as “a means but not the only means” for compliance with the
regulations, when software is used [5, 6]. DO-178B/ED-12B also addresses the use of
alternate methods (section 12.3). Because of this, some manufacturers have proposed
branch coverage as an alternative to decision coverage (not for MC/DC).
DO-178B/ED-12B (section 12.3), DO-248B/ED-94B (section 4.5) [7], and CAST-5 [8]
position paper provide some insight on both alternative methods and alternative means.
Each alternative method must be proposed, justified, and evaluated on a case-by-case
basis and must obtain the concurrence of the approving certification authority.
Each application of an alternative means or method may have slightly different nuances
to be evaluated. Some typical things to consider if branch coverage is proposed as an
alternate means or method for decision coverage are listed below (Note: this is not an all-
inclusive list):
o The developer should generate the test cases from the requirements.
o The developer should use normal range and robustness test cases to verify
the correct variable usage and Boolean operators for all software
requirements expressed by logical expressions (per 6.4.2.1d of DO-
178B/ED-12B).
o The developer should verify correct loop operations and correct logic
decisions (per 6.4.3 of DO-178B/ED-12B).
o The developer should establish and enforce standards and processes to
make sure that the alternative method or means is not being abused (i.e.,
using Boolean expressions outside of the components’ code-control
constructs to reduce the structural coverage effort).
8. NOTE: This position paper has been coordinated among the software specialists of certification
authorities from the United States, Europe, and Canada. However, it does not constitute official
policy or guidance from any of the authorities. This document is provided for educational and
informational purposes only and should be discussed with the appropriate certification authority
when considering for actual projects.
7
o Standards should be established and reviews should be performed to
ensure that the designer and/or programmer (either human or machine) is
not intentionally nor consistently using Boolean expressions outside of the
components’ code-control constructs to reduce the verification testing and
structural coverage analysis efforts (i.e., abusing the relaxation).
o The developer should perform additional testing and structural coverage
analysis, if the alternative method or means is not adequate (i.e., additional
test cases and manual structural coverage analysis may be needed to
address specific instances of violations discovered within the code).
6 References
[1] RTCA, Inc. document DO-178B and EUROCAE document ED-12B,
“Software Considerations in Airborne Systems and Equipment Certification”,
dated December 1, 1992.
[2] IEEE Std 100-1992, “The New IEEE Standard Dictionary of Electrical and
Electronics Terms,” Fifth Edition
[3] “A Practical Tutorial on Modified Condition/Decision Coverage,” published
jointly be NASA and FAA in 2001.
[4] Information based on John Chilenski’s (of The Boeing Company) Structural
Coverage Course.
[5] AC 20-115B, RTCA, Inc. Document RTCA/DO-178B, dated January 11,
1993.
[6] Temporary Guidance Leaflet Number 4 (TGL No. 4), which calls out ED-
12B for JAA.
[7] RTCA, Inc. document DO-248B and EUROCAE document ED-94B, “Final
Report for Clarification of DO-178B (/ED-12B) ‘Software Considerations In
Airborne Systems and Equipment Certification’”, 2001
[8] CAST-5 Paper, “Guidelines for Proposing Alternate Means of Compliance to
DO-178B,” Completed June, 2000