Documentation Source Text

<title>Quality Management</title>
<table_of_contents>

<h1>Overview</h1>

<p>
This is the Quality Management Plan for SQLite.

<p>
Quality management documents tend to expand into
binders full of incomprehensible legalise that nobody
reads.  This document strives to break that pattern by
being concise, and hence useful.

<p>
This document follows the outline of
[https://en.wikipedia.org/wiki/DO-178B|DO-178B] which
defines 21 outputs from the quality management process.
Each of those 21 outputs receives its own heading below,
even outputs that are not relevant to SQLite.
However, subsections within each output that are
not pertinent to SQLite are omitted or coalesced.

<p>
The [https://en.wikipedia.org/wiki/DO-178B|DO-178B]
process is designed for safety-critical airborne
software that is to be certified by safety
authorities.  SQLite is not (currently) a candidate for
certification and so DO-178B is not required.  DO-178B is
used purely because the developers find it helpful for
improving quality, and hence reducing their long-term 
maintenance workload.

<h1>Outputs From The Software Planning Process</h1>

<h2>Plan for Software Aspects of Certification (Output 1)</h2>

<ul>
<li><p>
<b>Software overview</b> &rarr;
See <a href='about.html'>About SQLite</a></p>

<li><p>
<b>Software life cycle</b> &rarr;
SQLite uses a continuous integration process.  The software
is under constant enhancement and refinement.  The latest trunk
check-ins are frequently used internally for mission-critical
operations.  There is no defined release cycle.  Users of
SQLite pick up new releases from the website on an as-needed
basis.

<li><p><b>Schedule</b> &rarr;
SQLite has a long-range vision.
Software planning is done with the assumption that the
software to be used and supported through at least the year 2050.

</ul>

<h2>Software Development Plan (Output 2)</h2>

<p>The following points summarize the philosophy behind SQLite
software development:
<ul>

<li><p>
<b>Agile.</b>
Development practices and processes are flexible and adapt quickly 
and easily to changing circumstances and in response to lessons learned.
</p></li>

<li><p>
<b>Low-ceremony.</b>
All developers are empowered to do whatever is needed. 
Audit trails are used rather than approval procedures.
Processes enable actions rather than prohibit them.
</p></li>

<li><p>
<b>Simple.</b>
Processes are easy to understand and follow.
The brain-power required to navigate the development process is minimized
so that developers can focus on improving the product.
It should be easier to use the defined processes than to circumvent them.
</p></li>

<li><p>
<b>Intuitive.</b>
Development processes follow the natural inclinations of highly
experienced top-ranked developers.
</p></li>

<li><p>
<b>Checklist Driven.</b>
Processes are describe by checklists rather than by
verbose planning documents in support of the priciples listed above and
in particular because
checklists are more easily adapted and enhanced,
checklists require less reading and are more easily understood, and
checklists can be followed quickly and with less disruption of thought
and work-flow.
</p></li>
</ul>



<h2>Software Verification Plan (Output 3)</h2>

<h2>Software Configuration Management Plan (Output 4)</h2>

<h2>Software Quality Assurance Plan (Output 5)</h2>

<h2>Software Requirements Standards (Output 6)</h2>

<h2>Software Design Standard (Output 7)</h2>

<h2>Software Coding Standard (Output 8)</h2>

<h1>Outputs From The Software Development Process</h1>

<h2>Software Requirements Data (Output 9)</h2>

<h2>Software Design Description (Output 10)</h2>

<h2>Source Code (Output 11)</h2>

<h2>Object Code (Output 12)</h2>

<h1>Outputs From The Software Integral Process</h1>

<h2>Software Verification Cases And Procedures (Output 13)</h2>

<h2>Software Verification Results (Output 14)</h2>

<h2>Software Configuration Management Records (Output 15)</h2>

<h2>Software Configuration Index (Output 16)</h2>

<h2>Problem Reports (Output 17)</h2>

<h2>Software Life-cycle Environment Configuration Index (Output 18)</h2>

<h2>Software Quality Assurance Records (Output 19)</h2>

<h2>Software Conformity Review (Output 20)</h2>

<h2>Software Accomplishment Summary (Output 21)</h2>