# Software development process: the life cycle explained for business owners

> How software gets built: the SDLC phases, waterfall, agile and DevOps, built-in security, build versus buy, cost drivers and how to judge a development partner.

- URL: https://computese.com/software-and-development/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2024-05-31
- Updated: 2026-09-25
- Topics: Custom software

## In short
- Software is built in a life cycle: discovery, requirements, design, build, test, release, then operation and maintenance. Each phase needs something from the business and should hand something back.
- Waterfall runs the phases once, in order. Agile methods such as Scrum run all of them in short cycles of a month or less, so you see working software early and can change priorities between cycles.
- Measure delivery with DORA's five metrics and build security in with NIST's Secure Software Development Framework (SP 800-218). Both give a buyer precise questions to ask.
- Buy what is standard, configure what is common and build only where your workflow sets you apart. Custom software is an asset that needs an owner and a budget for as long as it runs.
- Cost follows scope, roles, integrations, data migration, compliance and uncertainty. Price the first phase after discovery, and judge partners on frequent demos, code ownership, tests and recovery.

Software development is the work of turning a business need into working software and keeping it working. It runs through a life cycle: discovery, requirements, design, build, testing, release, then operation and maintenance. The delivery model a team uses, such as waterfall, agile or continuous delivery, decides how often it goes around that cycle.

This guide is for the person who commissions software rather than writes it: a founder, an operations manager, an owner with a budget and a problem. It walks through each phase with what you provide and what you should receive, compares the delivery models, shows where security belongs, and covers build versus buy, what drives cost and time, what a good brief contains and how to judge a development partner. If you want to learn to write code yourself, our [tips for new coders](https://computese.com/essential-tips-for-new-coders/) are the better start.

## What the software development life cycle is

The software development life cycle (SDLC) is the set of activities that takes software from an idea to a system people use, and on to its retirement. The international reference is [ISO/IEC/IEEE 12207](https://www.iso.org/standard/90219.html), whose second edition was published in April 2026. It covers the whole life of software, from conception through development, operation and support to retirement, including how it is bought and supplied. It deliberately does not prescribe a life cycle model: its processes can run concurrently, iteratively and recursively, and the 2026 edition notes that agile methods are the most widely used.

That point matters more than any diagram. The phases below are kinds of work, not calendar blocks. In a waterfall project each phase happens once, in order. In an agile project all of them happen in every short cycle, on a thin slice of the product. Either way, skipping a phase does not remove its work. It moves the work to a later and more expensive moment, usually after launch, when real users and real data are involved.

Two related terms come up often in conversations with suppliers:

- **Custom software development** is building software around one organization's own workflow, data and rules, instead of adapting the business to a product.
- **Software engineering** is the discipline behind it: the methods that let a team keep changing a system for years without breaking it.

## The phases of software development, and what you give and get at each

Every phase needs something from the business, and every phase should hand something back that you can inspect. If a supplier cannot tell you what you will receive at the end of a phase, you cannot tell whether it happened.

| Phase                | What happens                                                        | What the business provides                                                     | What the business receives                                                         |
| -------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| Discovery            | Users, the current process and constraints are researched           | Access to the people who do the work, examples of today's process, its costs   | A problem statement, research findings, a rough size and a go or stop decision     |
| Requirements         | What the first release must do is written down and made testable    | Decisions on priorities, business rules and edge cases; one person who decides | A prioritized scope (must, should, won't), user stories with acceptance criteria   |
| Design               | Screens, architecture, data model and security risks are worked out | Feedback on the prototype; hosting, integration and compliance constraints     | A clickable prototype, architecture decision records, a data model, a threat model |
| Build                | The software is written in short increments, each change reviewed   | Quick answers to questions, and people at every demo                           | Working software on a staging environment after each increment, repository access  |
| Test                 | Automated and manual tests prove it works, performs and is safe     | Realistic test data, and staff for user acceptance testing                     | Test results, security scan reports and a list of known issues                     |
| Release              | The software is deployed, data migrated and users switched over     | A release window that suits the business, and trained users                    | A live system, a runbook, a rollback plan and a handover                           |
| Operate and maintain | The system is monitored, patched, fixed and improved                | An owner and a budget after launch, and feedback from users                    | Incident and uptime reports, updates and a prioritized list of improvements        |

### Discovery

Discovery decides whether the problem is worth solving and what solving it would involve. The [UK government's Service Manual](https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works) describes it well: if you arrive with a solution ("we need an app that..."), reframe it as a problem first, research the users and the constraints (legislation, contracts, legacy systems), and work out what the problem costs today. It says not to start building during discovery, and that stopping at the end of discovery is not a failure when the research shows that is the right call. For government services it calls 4 to 8 weeks typical; a single internal workflow can take less.

### Requirements

Requirements turn findings into statements a developer can build and a tester can check. Functional requirements describe behaviour ("a manager must approve refunds over a set amount"). Non-functional requirements describe qualities: speed, availability, security, accessibility and how easy the system will be to change. [ISO/IEC 25010](https://www.iso.org/standard/78176.html) defines a model of nine product quality characteristics that teams use as a checklist for these, and later to write acceptance criteria. Agile teams usually keep requirements as user stories in a backlog; the format matters less than agreeing what "done" means before the work starts.

### Design

Design covers what people see (flows, screens and a clickable prototype) and what they do not (the architecture, the data model, the integrations and what happens when each one fails). Good teams record the big decisions with their reasons: which database, one application or several services, which parts are bought. The next team, or your own staff, can then understand why the system looks the way it does. Security design starts here too, with a threat model: a structured look at what could go wrong and who might try to make it happen.

### Build and test

In a healthy team every change goes into version control, is reviewed by a second developer and runs through automated checks before it is merged. Testing is not a phase that starts when coding ends. Unit tests check small pieces, integration tests check the parts together against a real database, end-to-end tests drive the application the way a user would, and security scans check the code and its third-party dependencies. Our overview of [test automation in 2026](https://computese.com/navigating-the-future-unveiling-10-cutting-edge-automation-testing-trends-of-2024/) covers the tools. User acceptance testing (UAT) is the part only you can do: people from the business run real tasks on a staging copy and confirm it does the job.

### Release

Release moves tested software into production. The first release of a new system often includes data migration from spreadsheets or an old system, a cut-over plan and training. Later releases should be the opposite of an event: small changes, deployed by an automated pipeline, with a rehearsed way to roll back.

### Operate and maintain

Launch starts the longest phase. Software needs monitoring, security patches, operating system and dependency updates, bug fixes, backups that have actually been restored, and a steady flow of changes as the business changes. Shortcuts taken during the build come due here as technical debt: every change takes longer and breaks more. Budget for this phase from the start and decide who is on call. If you would rather not run it yourself, [hosting and maintenance](https://computese.com/services/hosting-maintenance/) keeps an application hosted, patched, backed up with restore drills and watched from the outside.

## Waterfall, agile, Scrum and DevOps: how the delivery models differ

**Waterfall** runs the phases once, in sequence: requirements are signed off, then design, build, test and release follow. It suits work whose requirements are fixed and well understood, where change after sign-off is genuinely rare. Its weakness is timing: users see working software only at the end, which is also when misunderstandings surface and cost the most to fix.

**Agile** is a family of methods built on the [Manifesto for Agile Software Development](https://agilemanifesto.org/), written in 2001, which values working software over comprehensive documentation and responding to change over following a plan. Its [twelve principles](https://agilemanifesto.org/principles.html) ask teams to deliver working software frequently, from every couple of weeks to every couple of months with a preference for the shorter, and for business people and developers to work together daily. For a buyer the consequence is practical: progress arrives as software you can use rather than status reports, and priorities can change between cycles.

![Two lanes compared. Above, five stepped blocks end in one large parcel sent to a laptop and a phone at the end. Below, short loops each pass on a small parcel; the last, orange one reaches the same devices.](https://computese.com/images/blog/software-and-development/iterations.dedde77fb4-1536.webp)

*Iterative delivery puts working software in front of users after the first short cycle, while a wrong assumption is still cheap to fix.*

**Scrum** is an agile framework with fixed roles and a fixed rhythm. [The Scrum Guide](https://scrumguides.org/scrum-guide.html), whose current edition (as of September 2026) dates from November 2020, calls it a lightweight framework. Work happens in Sprints of one month or less. A Scrum Team, typically 10 or fewer people, has one Product Owner, one Scrum Master and the Developers, and each Sprint includes Sprint Planning, a Daily Scrum, a Sprint Review and a Sprint Retrospective. The Product Owner orders the Product Backlog, and the guide is explicit that this is one person, not a committee. Work counts only when it meets the team's Definition of Done, a written description of the quality every increment must reach.

**Kanban** drops the fixed cycle. [The Kanban Guide](https://kanbanguides.org/english/) defines it as a strategy for optimizing the flow of value through a process: make the workflow visible, actively limit work in progress, and keep improving the flow. It suits support and maintenance work that arrives continuously rather than in planned batches.

**DevOps and continuous delivery** carry agile past the developer's desk into deployment and operation. The people who build the software also deploy and run it, and automation does the repetitive parts. DORA defines [continuous delivery](https://dora.dev/capabilities/continuous-delivery/) as the ability to release changes of all kinds on demand, quickly, safely and sustainably. It is not the same as continuous deployment, which pushes every change to production as soon as possible. Continuous delivery applies to all kinds of software, including firmware, mainframe systems and highly regulated environments.

| Model               | How scope is planned                             | When you see working software    | Fits when                                                 |
| ------------------- | ------------------------------------------------ | -------------------------------- | --------------------------------------------------------- |
| Waterfall           | All up front, then signed off                    | At the end                       | Requirements are fixed and well understood                |
| Scrum               | An ordered backlog, re-planned every Sprint      | Every Sprint (one month or less) | A new product or workflow, where you will learn as you go |
| Kanban              | A continuous queue with limited work in progress | As each item is finished         | Support, maintenance and a steady stream of small changes |
| Continuous delivery | Small batches, alongside any of the above        | Whenever a change is ready       | Any system you plan to keep changing after launch         |

Most real projects mix them: a fixed-price discovery and first phase, Scrum for the build, Kanban-style flow after launch, and continuous delivery throughout.

## How to measure software delivery: DORA's five metrics

DORA, a research program run by Google Cloud, measures [software delivery performance](https://dora.dev/guides/dora-metrics/) with five metrics in two groups:

- **Throughput:** change lead time (from a commit in version control to production), deployment frequency, and failed deployment recovery time.
- **Instability:** change fail rate (the share of deployments that need immediate intervention, such as a rollback or a hotfix) and deployment rework rate (unplanned deployments caused by a production incident).

DORA's research has repeatedly found that speed and stability are not a trade-off: for most teams the metrics move together, and top performers do well on all five. Batch size is the practical reason. A small change is easy to review, test and roll back, so releasing often makes each release safer, not riskier. DORA's continuous delivery guidance points the same way: keep the software deployable at all times, fix a broken build before anything else, and keep branches short-lived.

![A small code change leaves a laptop and passes a gear, a check mark and a shield to reach a staging server, then production servers, with an orange dashed arrow leading back to the previous version.](https://computese.com/images/blog/software-and-development/pipeline.ed6bb56f9b-1536.webp)

*Small changes through the same automated gates, with a rehearsed way back, are how speed and stability improve together.*

For a buyer, these metrics are questions, not targets. Ask a prospective partner how long a one-line fix takes to reach production, how often they deploy and what happens when a deployment fails. DORA itself warns against turning the metrics into goals, which invites gaming (Goodhart's law), and against comparing very different systems such as a mobile app and a mainframe: the metrics are meant for one application or service at a time.

## Where security fits: NIST's Secure Software Development Framework

Security is not a phase. It is a set of practices attached to every phase. The standard reference is NIST's [Secure Software Development Framework (SSDF), SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final), version 1.1, published in February 2022. It starts from the observation that few SDLC models address security in detail, so its practices are meant to be added to whichever model a team uses. It is also written for buyers: purchasers can use its vocabulary to discuss security with their suppliers.

The [SSDF organizes its practices](https://csrc.nist.gov/projects/ssdf) into four groups:

| SSDF group                         | Its aim                                                              | What a buyer can ask to see                                                        |
| ---------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Prepare the Organization (PO)      | People, processes and technology ready for secure development        | Written security requirements for your project                                     |
| Protect the Software (PS)          | Every component protected from tampering and unauthorized access     | Who can change the code and release it; a record of the components in each release |
| Produce Well-Secured Software (PW) | Releases with minimal security vulnerabilities                       | The threat model, code review practice, security test and dependency scan results  |
| Respond to Vulnerabilities (RV)    | Remaining vulnerabilities found, fixed, and prevented from recurring | How to report a vulnerability, and how quickly fixes ship                          |

Version 1.1 added tasks for documenting security requirements (PO.1.2), collecting and sharing provenance data for every component of a release (PS.3.2), and tracking security requirements, risks and design decisions (PW.1.2). As of September 2026 it is still the final version: a draft [version 1.2, SP 800-218 Rev. 1](https://csrc.nist.gov/pubs/sp/800/218/r1/ipd), was published for comment in December 2025. For what these practices look like in code, see our [secure coding checklist](https://computese.com/best-practices-for-secure-coding/).

> [!IMPORTANT]
> Put security requirements in the brief and the contract, not in a later audit. A penetration test before launch can find problems, but it cannot add an access-control design the system never had.

## Build, buy or configure

Before commissioning anything, check whether you need to build at all. Accounting, payroll, e-signature and email are standard processes, and products already do them well. The real choice has four options, and it is made module by module, not once for the whole system:

| Option                      | Fits when                                                         | What you own                                                                               | Trade-off                                                   |
| --------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------- |
| Buy a product               | The process is standard                                           | Your data, as far as the vendor lets you export it                                         | Subscription fees, and the vendor decides the roadmap       |
| Configure a platform        | A common process with your own fields and steps, such as a CRM    | A configuration inside someone else's platform                                             | Hard limits at the edges, and moving off it takes a project |
| Extend with a custom module | A product covers most needs, and one workflow sets you apart      | The module and the [API contract](https://computese.com/the-future-of-enterprise-api-development/) it relies on | The module must follow every change the vendor makes        |
| Build                       | The workflow, data or rules are the business, and no product fits | Everything: code, data model, infrastructure                                               | You fund its upkeep for as long as it runs                  |

The [UK government's technology guidance](https://www.gov.uk/service-manual/technology/choosing-technology-an-introduction) suggests mapping the components of a service (it names Wardley mapping as one technique) to see what to build and what to buy or get for free. It also asks teams to minimize the total cost of ownership, including the risk of being locked into long contracts, and to keep full control of the data they store. Those two tests are a useful check whichever way you lean.

![Modules arranged around a central database: grey product boxes for standard tasks, one with slider controls that is configured, and one orange module with a wrench and gear built to fit.](https://computese.com/images/blog/software-and-development/buildbuy.a625cc2dd0-1536.webp)

*Decide module by module: buy the standard parts, and build only the one that sets the business apart.*

Custom software pays off where the workflow, the data or the rules are what set the business apart, or where no product meets your compliance needs. If the real need is to connect systems you already run, so data is entered once and stays in step, that is an [integration project](https://computese.com/services/integrations/) rather than a new application. If what you need is a marketing site, that is [web design and development](https://computese.com/services/web-design-development/), a different kind of project.

## What drives the cost and timeline of software

No one can price software honestly from a paragraph. A quote that arrives before anyone has studied the workflow is a price on risk, not on work. The cost follows a small set of drivers:

- **Workflows and user roles.** Each role (customer, staff, manager, administrator) multiplies screens, permissions and tests.
- **Integrations.** Every outside system, such as payments, accounting, identity or email, adds an interface to learn, failure cases to handle and a dependency to monitor.
- **Data migration.** Years of spreadsheets or an old database are rarely clean, and cleaning them needs business decisions, not only code.
- **Quality targets and compliance.** Uptime, speed, accessibility, audit trails, privacy law and industry rules each add design and testing work.
- **Uncertainty.** A new product idea has more unknowns than automating a process you already run by hand.
- **Running costs after launch.** Hosting, licences, provider fees, monitoring and maintenance continue for the life of the system.

The risk is not evenly spread. A [2022 study of 5,392 IT projects](https://arxiv.org/abs/2210.01573), published in the _Journal of Management Information Systems_, found that cost overruns follow a power-law distribution: many projects overrun a little, and a fat tail overruns enormously. The authors trace the tail to interdependencies between technical components, where a problem in one part sets off a chain reaction in others. The practical lesson is to estimate in ranges, to release a small first phase before committing to the whole, and to keep the number of moving parts in that first phase low.

That first phase is often an MVP: the smallest working release real users can rely on that still tests the business idea. It is not a prototype, which shows how something would work, and not a proof of concept, which shows that it can be built. When time runs short, cut scope before stretching the date.

The commercial model shapes who carries the risk:

| Model              | How it works                                              | Suits                                                    |
| ------------------ | --------------------------------------------------------- | -------------------------------------------------------- |
| Fixed price        | An agreed scope for an agreed price                       | A well-understood first phase, after discovery           |
| Time and materials | You pay for time spent and steer the scope as you learn   | Evolving products and requirements that are still moving |
| Dedicated team     | Engineers assigned to your roadmap at a monthly rate each | Long-running products that keep growing                  |

## What a good software brief contains

A brief is not a specification. It gives a development team enough to ask good questions and to produce a scope and a price. The US government's [Digital Services Playbook](https://playbook.usds.gov/) starts every project with understanding what people need, and the same order works for a business:

1. **The problem**, in business terms, and what it costs today in hours, errors or lost sales. Not the solution.
2. **The users**: the roles, roughly how many people, and the devices they use.
3. **Today's process**, with real examples: the spreadsheets, forms and email threads.
4. **What the first release must do**, and what can wait: must, should and won't.
5. **The systems it must connect to**, and who controls access to each one.
6. **The data**: what exists, where it lives, how much there is and who owns it.
7. **Constraints**: the privacy law that applies (in Canada, [PIPEDA](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/pipeda_brief/) covers private-sector organizations handling personal information in commercial activity, and Alberta, British Columbia and Quebec have their own substantially similar laws), industry rules, where data may be hosted, and accessibility. For anything on the web, [WCAG 2.2](https://www.w3.org/TR/WCAG22/) level AA is a common target, and its success criteria are written as testable statements; our [WCAG guide](https://computese.com/how-to-make-website-wcag-compliant/) explains the levels.
8. **Budget band and deadline**, and what drives the deadline.
9. **Who decides**: one named person with authority over scope and priorities.
10. **How you will know it worked**: the measure of success six months after launch.

> [!TIP]
> Attach examples. One real spreadsheet, a completed form and a forwarded email thread tell a developer more about your process than pages of description.

## How to judge a software development partner

A software development company designs, builds and tests software for clients, and often hosts and maintains it afterwards. Portfolios and day rates are easy to compare. How a team works decides the outcome, and most of it can be checked before you sign. The [Digital Services Playbook](https://playbook.usds.gov/) is a useful checklist here even outside government: it asks for a budget that includes discovery and prototyping, frequent deliverables rather than multi-month milestones, software and data that stay under the buyer's control, a warranty period for defects and a transition-out plan, with a single product owner accountable on the buyer's side.

Questions worth asking:

1. **How often will we see working software?** Ask for demos on a staging environment you can use yourself, after every increment.
2. **Who owns the code, the data and the accounts?** The repository, cloud accounts and domain should be yours, or transfer to you, with everything needed to build and deploy the system written down.
3. **How is quality built in?** Ask about code review, automated tests, the staging environment and what their Definition of Done includes.
4. **How do you deliver and recover?** Ask for their DORA metrics, or more simply how long a small fix takes to reach production and how they roll back a bad release.
5. **How do you handle security?** Ask which SSDF practices they follow, how dependencies are scanned, and how a vulnerability reported after launch is fixed.
6. **How do you use AI coding assistants?** [DORA's 2025 report](https://dora.dev/research/2025/dora-report/) found that AI acts as an amplifier of a team's existing strengths and weaknesses, so the real question is what review and testing surround it.
7. **What happens after launch?** Agree the warranty period, support hours, who is on call, and the runbook and handover if the work later moves elsewhere.

Where the company is based matters less than these answers. Overlapping working hours, the law that governs the contract and where your data will be hosted are the location questions that count.

If you are weighing a build, our [custom software development](https://computese.com/services/custom-software-development/) work starts with a short, fixed-price scope and architecture sprint: the first release defined, prototyped and priced, with a written scope, a clickable prototype and a fixed price for phase one. The plan is yours even if you stop there, and if a product fits better, we will say so and help you choose it.

## Key terms
- **Software development life cycle (SDLC)**: The activities that take software from an idea to a system in use and on to retirement: discovery, requirements, design, build, test, release, and operation and maintenance.
- **Discovery**: The research phase before any build: who the users are, what the problem costs today, what constrains a solution, and whether it is worth continuing.
- **Non-functional requirements**: Requirements about qualities rather than features, such as speed, availability, security, accessibility and how easy the system is to change.
- **Agile**: A family of methods based on the 2001 Agile Manifesto that deliver working software in short cycles and adjust the plan as the team and the business learn.
- **Scrum**: An agile framework defined by the Scrum Guide: Sprints of one month or less, a Product Owner who orders the backlog, a Scrum Master and the Developers.
- **Continuous delivery**: The ability to release changes of all kinds on demand, quickly, safely and sustainably, usually through an automated build, test and deployment pipeline.
- **DORA metrics**: Five software delivery measures from Google Cloud's DORA research: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
- **SSDF**: NIST's Secure Software Development Framework (SP 800-218): secure development practices in four groups that can be added to any SDLC model.
- **MVP (minimum viable product)**: The smallest working release that real users can rely on and that still tests the business idea. Unlike a prototype, it is production software.
- **Technical debt**: The future cost of shortcuts taken today, such as missing tests or a rushed design, paid back later as slower and riskier changes.

## Common questions

### What is software development?

Software development is the process of designing, building, testing, releasing and maintaining software. For a business it usually means commissioning a system built around its own workflow, data and rules, called custom software, instead of adapting the business to an off-the-shelf product.

### What are the phases of the software development life cycle?

Discovery, requirements, design, build, test, release, and operation and maintenance. Lists differ in how they split and name them, and the international standard, ISO/IEC/IEEE 12207, does not prescribe a model. In agile projects every phase happens in every short cycle.

### What is the difference between agile and waterfall?

Waterfall runs each phase once, in sequence, so users see working software only at the end. Agile runs all phases in short cycles, delivering working software every few weeks and re-planning between cycles. Waterfall suits fixed, well-understood requirements; agile suits work where you will learn as you go.

### How much does custom software development cost?

It depends on the number of workflows and user roles, the integrations, data migration, compliance needs and how uncertain the idea is. An honest price comes after discovery: a fixed price for a defined first phase, with a range for the rest, rather than one number for a whole product nobody has studied yet.

### How long does it take to build custom software?

It depends on the scope of the first release. The UK government's Service Manual calls 4 to 8 weeks typical for a discovery on its own services, and the build is sized from there. Cut scope before stretching the date, and ask for a range tied to a written scope.

### What does a software development company do?

It turns a business need into working software: discovery, design, build, testing and release, and often hosting and maintenance afterwards. Where it is based matters less than overlapping working hours, who owns the code and data, and which privacy law applies, such as PIPEDA or a substantially similar provincial law in Canada.

## Sources
1. [ISO/IEC/IEEE 12207:2026 Systems and software engineering: Software life cycle processes](https://www.iso.org/standard/90219.html), ISO
2. [How the discovery phase works](https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works), GOV.UK Service Manual
3. [ISO/IEC 25010:2023 Product quality model](https://www.iso.org/standard/78176.html), ISO
4. [Manifesto for Agile Software Development](https://agilemanifesto.org/), Agile Manifesto authors
5. [Principles behind the Agile Manifesto](https://agilemanifesto.org/principles.html), Agile Manifesto authors
6. [The 2020 Scrum Guide](https://scrumguides.org/scrum-guide.html), Ken Schwaber and Jeff Sutherland
7. [The Kanban Guide (May 2025)](https://kanbanguides.org/english/), Kanban Guides
8. [Continuous delivery](https://dora.dev/capabilities/continuous-delivery/), DORA (Google Cloud)
9. [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics/), DORA (Google Cloud)
10. [SP 800-218: Secure Software Development Framework (SSDF) Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final), NIST
11. [Secure Software Development Framework (SSDF) project](https://csrc.nist.gov/projects/ssdf), NIST Computer Security Resource Center
12. [SP 800-218 Rev. 1 (Initial Public Draft): SSDF Version 1.2](https://csrc.nist.gov/pubs/sp/800/218/r1/ipd), NIST
13. [Choosing technology: an introduction](https://www.gov.uk/service-manual/technology/choosing-technology-an-introduction), GOV.UK Service Manual
14. [The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution](https://arxiv.org/abs/2210.01573), Journal of Management Information Systems (arXiv)
15. [Digital Services Playbook](https://playbook.usds.gov/), U.S. DOGE Service
16. [PIPEDA requirements in brief](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/pipeda_brief/), Office of the Privacy Commissioner of Canada
17. [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), W3C
18. [2025 State of AI-assisted Software Development](https://dora.dev/research/2025/dora-report/), DORA (Google Cloud)