+This is the Quality Management Plan for SQLite. + +
+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. + +
+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. + +
+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. + +
+Software overview → +See About SQLite
+ ++Software life cycle → +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. + +
Schedule → +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. + +
The following points summarize the philosophy behind SQLite +software development: +
+Agile. +Development practices and processes are flexible and adapt quickly +and easily to changing circumstances and in response to lessons learned. +
+Low-ceremony. +All developers are empowered to do whatever is needed. +Audit trails are used rather than approval procedures. +Processes enable actions rather than prohibit them. +
+Simple. +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. +
+Intuitive. +Development processes follow the natural inclinations of highly +experienced top-ranked developers. +
+Checklist Driven. +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. +