bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
Wiki Markup
{alias:SWE-106} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1.Requirement
Div
idtabs-1

1.Requirement

5.1.5.1

The

Software

Assurance

Plan(s)

shall

be

developed

and

documented

per

NASA-STD-8739.8,

NASA

Software

Assurance

Standard.

h2.

[SWE-106]

1.2

Notes

NPR

7150.2

does not include any notes for this requirement. h2.

, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.3

Applicability

Across

Classes

{applicable:asc=1\|ansc=1\|bsc=1\|bnsc=1\|csc=1\|cnsc=1\|dsc=1\|dnsc=0\|esc=1\|ensc=0\|f=1\|g=1\|h=0} {div3}{div3:id=tabs-2} h1. 2. Rationale Software assurance activities ensure that the project team implements software engineering products and processes according to the plans established by the project and comply with requirements in the NASA Software Assurance Standard. The [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130] captures the assurance requirements in a single place for more uniform application across projects where software is developed or acquired for NASA. The Software Assurance Plan represents an agreement between the project, the software developers and the software assurance personnel. It describes the activities, roles, and responsibilities of software assurance on the project. As with any task, a plan helps ensure that the team performs all necessary and required tasks. Development of that plan provides the opportunity for stakeholders to give input and assist with the documentation and tailoring of the planned activities for the project. Specific to software assurance, the [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130] provides requirements that the team can use as the basis for development of a project's software assurance plan. Using this previously thought-out, defined set of requirements gives plan development teams a common starting point for their activities and ensures that all software assurance plans include and address the same key tasks and assurance activities. {div3}{div3:id=tabs-3} h1. 3. Guidance ?{floatbox:width=full} Per NPR 7150.2, "_The Software Assurance Plan details the procedures, reviews, and audits required to accomplish software assurance. The project office should coordinate with the Office of Safety and Mission Assurance for help in scoping and adapting the effort appropriately, and to designate the individual responsible for software assurance on the project."    {floatbox} For projects that involve subcontracted work, both the acquirer and the provider (subcontractor), need Software Assurance Plans and those plans must work together to accomplish the required level of software assurance. The preliminary acquirer plan is developed at the same time the Request for Proposal (RFP) or Memorandum of Agreement/Understanding (MOA/U) is created. Both acquirer and provider plans are to be completed by the time the contract is awarded, though an update of the provider plan is expected at the SwRR. As with many project plans, the Software Assurance Plan (SAP) may be a separate document or may be combined with another project plan such as the Software Development Plan (SDP).  However, the independent software assurance organization of the Center SMA Office needs to have sign-off authority on the content no matter what document the SAP contents may be incorporated into.  The SAP is a joint agreement between Center SMA and the project/Facility for software assurance activities. While the [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130] contains requirements for software assurance in general, the following requirements, identified by the paragraph numbers, apply specifically to the development and documentation of a SAP. These requirements, shown here without their associated project life cycle phase, provide a high-level content overview of both the acquirer and provider SAPs. When carrying out these requirements, consult the [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130] to determine the specific life cycle phase in which they are to be completed. *Acquirer SAP:* * 5.1.2.8 - Prepare a preliminary acquirer program/project software assurance plan documenting the planned level of software assurance effort and activities required and the necessary resources using the template provided in Appendix B \[of the [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130]\]. * 5.3.1.1 - Verify that the provider's software assurance plan meets contractual requirements. * 5.3.1.2 - Verify that the acquirer's software assurance plan and the provider's software assurance plan are consistent, compatible, and are base-lined. *Provider SAP:* * 6.3.1 - Each software provider shall establish and maintain a software assurance plan that addresses all software development and maintenance activities. NOTE: For smaller projects, this plan may be incorporated in another project-planning document or may be a separate document. Larger projects may have a separate plan or more than one software assurance plan. * 6.3.2 - The software assurance plan shall: * 6.3.2.1 - Conform to IEEE 730-2002, IEEE Standard for Software Quality Assurance Plans. * 6.3.2.2 - In addition, address how the provider will implement the requirements of Sections 6.0 and 7.0 of this Standard \[[NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130]\]. The [NASA Software Safety Standard|https://standards.nasa.gov/documents/detail/3314914] (NASA-STD-8719.13B) also includes two requirements that address content to consider for the SAP: * 6.2.2.1 - The ?\[safety\] analysis methodology \[for software design\] shall be recorded in an appropriate document (e.g., software safety plan or software assurance plan). * 6.2.3.1 - The ?\[safety\] analysis methodology \[for software implementation, e.g., code\] shall be recorded in an appropriate document (e.g., software safety plan or software assurance plan). Before writing a SAP, the team should review the following material as preparation: * Software assurance lessons learned from similar projects * Existing software assurance processes, standards, procedures, etc. * Software assurance deliverables (records, reports, etc.) for similar projects Using an existing template will ensure consistency of plans across projects as well as ensure all key information is included in the SAP. If a project or Center SAP template or "best-in-class" example does not exist, the [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130] (NASA-STD-8739.8) contains a basic outline in Appendix B. Templates are included in the Resources section of this guidance, including one from Goddard Space Flight Center (GSFC) based on the IEEE 730-2002 standard noted in the [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130] requirements which includes suggested content for each section of the SAP. Other content elements to consider include: * Software assurance organization and management structure and responsibilities * Software assurance planning activities * Software assurance implementation activities covering all 5 assurance disciplines: ** Software Quality ** Software Safety ** Software Reliability ** Software Verification and Validation ** Independent Verification and Validation * Standards and processes to be used, including those used for: ** Software assurance implementation activities such as reviews, audits, etc. ** Problem reporting and tracking ** Risk management ** Software assurance metrics (e.g., planned vs. actual reviews, audits, assessments; open vs. closed issues; number of identified risks; etc.) ** Record creation, review, and maintenance * Training for software assurance personnel * Resources, including tools, personnel, and facilities * Identification of products and processes to be reviewed or audited * Identification of deliverables (records) to be created and maintained * Schedule Ensure that the SAP is [reviewed prior to implementation|https://nasa7150.onconfluence.com/display/7150/7.4+-+Maturity+of+Lifecyle+Products+at+Milestone+Reviews] and at [appropriate life cycle reviews|https://nasa7150.onconfluence.com/display/7150/7.3+-+Entrance+and+Exit+Criteria] by personnel with sufficient software assurance knowledge to identify omissions, inadequacies, and other issues. Stakeholders affected by the plan should also be included in the reviews for awareness of planned activities and so that their suggestions can be addressed within the bounds of the project's required level of software assurance. Any identified issues should be corrected prior to plan implementation or prior to carrying out affected software assurance activities in the next life cycle phase. The following diagram excerpted from the Glenn Research Center SQA Process for Software Assurance, SEGP-SQA-PRC-1{^}5^, shows a basic flow of activities for developing and documenting a SAP: !swassurance1.png! Any changes to the base-lined SAP (typically base-lined at PDR) should be made via the appropriate formal change request process (internal to the project for the acquirer SAP or via NASA's formal change request process for the provider SAP) and be accompanied by a risk analysis to ensure the project's level of software assurance is not compromised. Guidance related to software assurance and which should be included in the SAP may be found in the following topics and requirements in this handbook: | [SWE-013|SWE-013] | Software Plans | | [SWE-020|SWE-020] | Software Classification | | ?[SWE-022|SWE-022] | Software Assurance | | [SWE-132|SWE-132] | Independent Software Classification Assessment | | [SWE-133|SWE-133] | Software Safety Determination | \\ {div3}{div3:id=tabs-4} h1. 4. Small Projects According to the [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130], smaller projects have the choice of incorporating their SAP in another project planning document or using a separate document. If personnel resources are limited, the SAP may address the overall strategy, planning, and requirements at a high level for review at the Software Requirements Review (SRR), with updates to address details of the assurance activities added, as necessary, during project development. Small projects may want to tailor an existing software assurance plan specifically written for small projects. Tailoring a proven plan from a similar project should reduce the overall plan development effort. {div3}{div3:id=tabs-5} h1. 5. Resources # NPR 7150.2A Handbook, Section 5.3.1 - NASA-STD-8739.8 (Standard for Software Assurance) # NASA Technical Standard, [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130], NASA-STD-8739.8, 2004. # Information System Division, Goddard Space Flight Center, [ISD Software Quality and IV&V Support Planning Guidelines|http://software.gsfc.nasa.gov/AssetsApproved/PA3.2.1.1.doc], 580-GL-030-01, 2005. # Software Assurance, Dryden Flight Research Center, [Dryden Centerwide Procedure, Code S, Software Assurance|http://www.nasa.gov/centers/dryden/pdf/87463main_DCP-S-007.pdf], DCP-S-007 Rev. B, Expires 2013. # Glenn Research Center, [SQA Process, Software Assurance|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499233%2FSoftware.Assurance.pdf], SEGP-SQA-PRC-1. # Safety and Mission Assurance, Glenn Research Center, Glenn Procedural Requirements, [Software Assurance|https://knowledgeshare.grc.nasa.gov/eRoomReq/Files/NASAc1f1/GRCKnowledgeBase/0_d700/GLPR%208739%201.pdf], GLPR 8739.1, 2007. # Software Engineering Process Group, Glenn Research Center, Software Process, [Process and Product Quality Assurance|http://software.grc.nasa.gov/processes/SEPG_Processes/Process%20and%20Product%20Quality%20Assurance.pdf], GRC-SW-7150.13, 2008. # IEEE Computer Society, "[IEEE Standard for Software Quality Assurance Plans|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1040117&tag=1]", IEEE 730-2002 (need user account to access IEEE standards via this [NASA Technical Standards System|http://standards.nasa.gov/] link). # Goddard Space Flight Center, [Software Quality Assurance Plan template|http://software.gsfc.nasa.gov/AssetsApproved/PA3.2.1.2.doc], Rev. 2.0. # [Software Assurance Plan template|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499256%2FSEPGSoftwareAssurancePlanTemplate.doc.doc]. # [Software Quality Assurance Plan Evaluation Checklist|http://sato.gsfc.nasa.gov/guidebook/assets/Assurance_Plan_Evaluation_Checklist.doc] (from the Software Assurance Guidebook). # [Acquirer Software Assurance Plan template|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-500056%2FNASA-STD-8739.8%2BAcquirer%2BSoftware%2BAssurance%2BPlan%2Btemplate.doc]. {toolstable} {div3}{div3:id=tabs-6} h1. 6. Lessons Learned There must be a software assurance plan.  "Most Project Managers feel they have too many plans, and the suggestion of another one for Software Quality Assurance might be the proverbial straw that breaks the camel's back\! But the success of any undertaking is to know what one is trying to achieve and how one expects to accomplish it, hence, the necessity of a plan for SQA. The plan will specify the goals, what is to be performed, standards against which the development work is to be measured, all relevant procedures, and the organizational structure of the Quality Assurance within the project. At NASA a software assurance plan is required." (Lesson 4 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61]) The NASA Lesson Learned database contains the following lessons learned related to software assurance planning: * *Quality Assurance Access*: "If program or engineering management exercises the authority to deny QA access to critical areas, QA over-site will be severely \[compromised\]."  \[Note that while this lesson does not specifically call out software, the lesson remains relevant regarding assurance personnel access to information and areas required to perform software assurance activities.\] ([http://www.nasa.gov/offices/oce/llis/0332.html|http://www.nasa.gov/offices/oce/llis/0332.html]) * *Quality Assurance Expertise*: "If quality assurance personnel responsible for oversight of the quality of highly technical state-of-the-art development do not have a degree of expertise in that technical area, the likelihood of discovering QA problems decreases significantly." \[Note that while this lesson does not specifically call out software, the lesson remains relevant regarding assurance personnel access to information and areas required to perform software assurance activities.\] ([http://www.nasa.gov/offices/oce/llis/0331.html|http://www.nasa.gov/offices/oce/llis/0331.html]) * *Schedules:* "The ISS software development schedule is almost impossibly tight. If something else does not cause a further delay in ISS deployment, software development may very well do so. The decision this year to add integrated testing of some modules ... is a very positive step for safety. However, there is no room in the schedule for required changes that may be discovered during this testing." ([http://www.nasa.gov/offices/oce/llis/1062.html|http://www.nasa.gov/offices/oce/llis/1062.html]) {div3} {tabclose}


applicable
f1
g1
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnsc0
dsc1
ensc0

Div
idtabs-2

2. Rationale

Software assurance activities ensure that the project team implements software engineering products and processes according to the plans established by the project and that these products and projects comply with requirements in NASA-STD-8739.8. NASA-STD-8739.8

sweref
278
278
 captures the assurance requirements in a single place for more uniform application across projects where software is developed or acquired for NASA.

The Software Assurance Plan (SAP) represents an agreement between the project, the software developers, and the software assurance personnel. It describes the activities, roles, and responsibilities of software assurance on the project. As with any task, a plan helps ensure that the team performs all necessary and required tasks. Development of the plan provides the opportunity for stakeholders to give input and assist with the documentation and tailoring of the planned activities for the project.

Specific to software assurance, NASA-STD-8739.8

sweref
278
278
 provides requirements that the team can use as the basis for development of a project's SAP. Using this previously thought-out, defined set of requirements gives plan development teams a common starting point for their activities and ensures that all SAPs include and address the same key tasks and assurance activities.

Div
idtabs-3

3. Guidance


Floatbox
widthfull

NPR 7150.2, section 5.1.5, states that: "The Software Assurance Plan details the procedures, reviews, and audits required to accomplish software assurance. The project office should coordinate with the Office of Safety and Mission Assurance for help in scoping and adapting the effort appropriately, and to designate the individual responsible for software assurance on the project."   


For projects that involve contracted work, both the acquirer and the provider (subcontractor) need SAPs, and those plans must work together to accomplish the required level of software assurance. The preliminary acquirer plan is developed at the same time that the Request for Proposal (RFP) or Memorandum of Agreement/Memorandum of Understanding (MOA/MOU) is created. Both acquirer and provider plans are to be completed by the time the contract is awarded, though an update of the provider plan is expected at the Software Requirements Review (SwRR).

As with many project plans, the SAP may be a separate document or may be combined with another project plan such as the Software Development Plan (SDP). However, the independent software assurance organization of the acquirer Safety and Mission Assurance (SMA) Office needs to have sign-off authority on the content no matter into what document the SAP contents may be incorporated. The SAP is a joint agreement between acquirer SMA and the project/facility for software assurance activities.

While NASA-STD-8739.8

sweref
278
278
 contains requirements for software assurance in general, it also contains minimum content requirements for the SAP. The following requirements, identified by NASA-STD-8739.8 paragraph numbers, apply specifically to the development and documentation of a SAP. These requirements, shown here without their associated project life-cycle phase, provide a high-level content overview of both the acquirer and provider SAPs. When carrying out these requirements, consult NASA-STD-8739.8
sweref
278
278
 to determine the specific life-cycle phase in which they are to be completed.

Acquirer SAP:

  • 5.1.2.8 - Prepare a preliminary acquirer program/project software assurance plan documenting the planned level of software assurance effort and activities required and the necessary resources using the template provided in Appendix B [of NASA-STD-8739.8
    sweref
    278
    278
    ].
  • 5.3.1.1 - Verify that the provider's software assurance plan meets contractual requirements.
  • 5.3.1.2 - Verify that the acquirer's software assurance plan and the provider's software assurance plan are consistent, compatible, and are baselined.

Provider SAP:

  • 6.3.1 - Each software provider shall establish and maintain a software assurance plan that addresses all software development and maintenance activities.
    NOTE: For smaller projects, this plan may be incorporated in another project-planning document or may be a separate document. Larger projects may have a separate plan or more than one software assurance plan.
  • 6.3.2 - The software assurance plan shall:
  • 6.3.2.1 - Conform to IEEE 730-2002, IEEE Standard for Software Quality Assurance Plans
    sweref
    218
    218
    .
  • 6.3.2.2 - In addition, address how the provider will implement the requirements of Sections 6.0 and 7.0 of this Standard [NASA-STD-8739.8
    sweref
    278
    278
    ].

 NASA-STD-8719.13B, Software Safety Standard,

sweref
271
271
 also includes two requirements that address content to consider for the SAP:

  • 6.2.2.1 - The [safety] analysis methodology [for software design] shall be recorded in an appropriate document (e.g., software safety plan or software assurance plan).
  • 6.3.2.1 - The [safety] analysis methodology [for software implementation, e.g., code] shall be recorded in an appropriate document (e.g., software safety plan or software assurance plan).

Before writing a SAP, it is recommended that the team review the following material as preparation:

  • Software assurance lessons learned from similar projects.
  • Existing software assurance processes, standards, procedures, etc.
  • Software assurance deliverables (records, reports, etc.) for similar projects.

Using an existing template will ensure consistency of plans across projects, as well as ensure all key information is included in the SAP. If a project or Center SAP template or "best-in-class" example does not exist, NASA-STD-8739.8

sweref
278
278
 contains a basic outline in its Appendix B. Templates are included in the Resources section of this guidance, including one from Goddard Space Flight Center (GSFC) based on IEEE 730-2002 noted in NASA-STD-8739.8
sweref
278
278
 requirements, which includes suggested content for each section of the SAP.

Other content elements to consider include:

  • Software assurance organization and management structure and responsibilities.
  • Software assurance planning activities.
  • Software classification and safety criticality.
  • Software assurance implementation activities covering all five assurance disciplines:
    • Software Quality (includes software quality assurance, software quality engineering, and software quality control).
    • Software Safety.
    • Software Reliability.
    • Software Verification and Validation.
    • Independent Verification and Validation.
  • Standards and processes to be used, including those used for:
    • Software assurance implementation activities, such as reviews, audits, etc.
    • Problem reporting and tracking.
    • Risk management.
    • Software assurance metrics, e.g., planned versus actual reviews, audits, assessments; open versus closed issues; number of identified risks.
    • Record creation, review, and maintenance.
  • Training for software assurance personnel.
  • Resources, including tools, personnel, and facilities.
  • Identification of products and processes to be reviewed or audited.
  • Identification of deliverables (records) to be created and maintained.
  • Schedule.

Ensure that the SAP is reviewed prior to implementation (see Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews) and at appropriate life cycle reviews (see Topic 7.09 - Entrance and Exit Criteria) by personnel with sufficient software assurance knowledge to identify omissions, inadequacies, and other issues. Include stakeholders affected by the plan in the reviews for awareness of planned activities and so that their suggestions can be addressed within the bounds of the project's required level of software assurance. Any identified issues need to be corrected before plan implementation or before carrying out affected software assurance activities in the next life-cycle phase.

The following diagram excerpted from the Glenn Research Center SQA Process for Software Assurance, SEGP-SQA-PRC-1

sweref
382
382
, shows a basic flow of activities for developing and documenting a SAP:

Image Added

Any changes to the baselined SAP (typically baselined at PDR (Preliminary Design Review)) need to be made via the appropriate formal change request process (internal to the project for the acquirer SAP or via NASA's formal change request process for the provider SAP) and be accompanied by a risk analysis to ensure the project's level of software assurance is not compromised. 

The acquirer software assurance personnel are responsible for ensuring the provider software assurance personnel are meeting the contents of the provider SAP. The acquirer SAP describes how this will be done (based on software size, software class, safety criticality, and other factors that may be specific to a project). 

Guidance related to software assurance and to be considered for inclusion in the SAP may be found in the following related requirements in this Handbook:


SWE-013

Software Plans

SWE-020

Software Classification

SWE-022

Software Assurance

SWE-132

Independent Software Classification Assessment

SWE-133

Software Safety Determination



Div
idtabs-4

4. Small Projects

According to NASA-STD-8739.8

sweref
278
278
, smaller projects have the choice of incorporating their SAP in another project-planning document or using a separate document.

Div
idtabs-5

5. Resources


refstable

toolstable

Div
idtabs-6

6. Lessons Learned

There must be a software assurance plan.  "Most Project Managers feel they have too many plans, and the suggestion of another one for Software Quality Assurance might be the proverbial straw that breaks the camel's back! But the success of any undertaking is to know what one is trying to achieve and how one expects to accomplish it, hence, the necessity of a plan for SQA. The plan will specify the goals, what is to be performed, standards against which the development work is to be measured, all relevant procedures, and the organizational structure of the Quality Assurance within the project. At NASA a software assurance plan is required." (Lesson 4 of 12, SoftwareTech News

sweref
433
433
).

The NASA Lesson Learned database contains the following lessons learned related to software assurance planning:

  • Quality Assurance Access to Critical Areas, Management (Quality Assurance Access). Lesson Number 0332: "If program or engineering management exercises the authority to deny QA (Quality Assurance) access to critical areas, QA oversite will be severely [compromised]."  [Note that, while this lesson does not specifically call out software, the lesson remains relevant regarding assurance personnel access to information and areas required to perform software assurance activities.]
    sweref
    503
    503
  • Quality Assurance Expertise in Special Technical Areas (e.g., optics) (Quality Assurance Expertise). Lesson Number 0331: "If quality assurance personnel responsible for oversight of the quality of highly technical state-of-the-art development do not have a degree of expertise in that technical area, the likelihood of discovering QA problems decreases significantly." [Note that, while this lesson does not specifically call out software, the lesson remains relevant regarding assurance personnel access to information and areas required to perform software assurance activities.]
    sweref
    502
    502
  • International Space Station (ISS) Program/Computer Hardware-Software/Software (Schedules). Lesson Number 1062: "The ISS software development schedule is almost impossibly tight. If something else does not cause a further delay in ISS deployment, software development may very well do so. The decision this year to add integrated testing of some modules ... is a very positive step for safety. However, there is no room in the schedule for required changes that may be discovered during this testing."
    sweref
    536
    536