Software Development Process Flow Chart: Steps, Symbols, Examples and a Free Template

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

A software development process flow chart turns a sequence that usually lives in people’s heads into a picture anyone can follow in a minute. It shows which step comes first, who owns it, where a decision is made, and what happens when a review or a test fails. For a new hire, it explains how work gets done. For a client, it shows where they will be asked to approve something. For a manager, it exposes the handoffs where work tends to stall.

On client projects we draw this diagram in the first week, because it is the fastest way to agree how the custom software development process will run: when requirements are frozen, who signs off on designs, what “done” means for a sprint and how a release reaches production. A process flow diagram of software development is also the document people look at most when something goes wrong, because it shows which gate was skipped.

This guide explains what a software development flow chart is, walks through the standard stages and decision points, lists the symbols you need, and shows ready-made patterns for swimlane, waterfall, agile, V-model and DevOps flows. It ends with a six-step method, a copy-ready Mermaid template, a tool comparison and answers to the most common questions.

What Is a Software Development Process Flow Chart?

A software development process flow chart is a diagram that represents the steps of building software as connected shapes: rectangles for activities, diamonds for decisions, arrows for the order of work and rounded shapes for the start and the end. It describes the process, not the code, so it answers “how does our team get from an idea to working software?”.

The format is old. Industrial engineers Frank and Lillian Gilbreth presented their “process charts” to the American Society of Mechanical Engineers in 1921, and the common flowchart symbols used in computing were standardised in ISO 5807, published in 1985. Software teams adopted the same visual language because it is simple: almost anyone can read a box-and-arrow diagram without training.

A good software development process flow diagram does three jobs at once:

• It sets the order of work: requirements before design, design before build, tests before release.
• It names owners: every step has one person or role who is accountable for it.
• It makes decisions explicit: approvals, quality checks and go/no-go points are drawn as diamonds with a “yes” and a “no” path.

Flow chart vs process flow diagram vs data flow diagram

The three terms are related but describe different things, and mixing them up leads to diagrams that try to show everything and explain nothing.

For mapping how your team builds software, a flow chart or a swimlane process flow diagram is almost always enough. Reach for BPMN, standardised as ISO/IEC 19510 in 2013, only when the diagram will drive a workflow engine or must follow a formal company standard.

The Standard Software Development Process Flow, Step by Step

Most software development process flow charts follow the same backbone of eight stages, whatever methodology the team uses: idea, requirements, design, development, testing, acceptance, deployment and maintenance. The methodology changes how often you loop through these stages and how big each pass is, not the stages themselves. The table below is the reference flow we start from on new projects.

Each “no” answer at a gate is an arrow back to an earlier stage, and drawing those loops is what separates a useful flow chart from a straight list of phases. A failed test goes back to development, a rejected design goes back to design, and a production incident creates a new item in the backlog. If you want the theory behind these stages, our software development life cycle guide covers each phase and the classic SDLC models in depth.

Decision points every flow chart should show

The decision diamonds carry more information than the boxes, because they show where work can stop. Five gates appear in almost every healthy software process:

1. Requirements sign-off: the business owner confirms scope and acceptance criteria before design starts.
2. Design approval: architecture and UX are reviewed so expensive changes happen on paper, not in code.
3. Code review and CI check: no change is merged without a second pair of eyes and a green automated build.
4. Release readiness: testing is complete, no open critical defects remain and a rollback plan exists.
5. Post-release check: monitoring confirms the release is healthy; if not, the team rolls back or hot-fixes.

Acceptance deserves its own diamond because it is the one gate owned by the client rather than the team. Our explainer on user acceptance testing shows how to run it so sign-off is a formality, not a surprise.

Which Flowchart Symbols Do You Need?

You need only six or seven symbols to draw a clear software development process flow chart; the rest of the ISO 5807 set is rarely useful for process maps. Keeping the vocabulary small makes the diagram readable for non-technical stakeholders.

Arrows always point in the direction of work, and every decision diamond needs labelled exits. An unlabelled arrow leaving a diamond is the most common reason a flow chart gets misread.

Swimlane Flow Chart: Who Does What in Software Development?

A swimlane flow chart splits the diagram into horizontal or vertical lanes, one per role, so you can see who owns each step and where work is handed over. It is the most useful format for software teams, because most delays happen at handoffs, not inside a step.

A typical software development swimlane diagram has five or six lanes:

Every arrow that crosses from one lane to another is a handoff, and each handoff needs a clear trigger (“story moved to Ready for QA”) and an artefact (a build, a ticket, a document). If you manage work in Jira, map the lanes and statuses to your board so the chart and the tool tell the same story; our Jira workflow guide shows a setup that mirrors this flow.

Software Development Process Flow Chart Examples by Model

The shape of the flow chart depends on the development model: waterfall is a straight line with gates, agile is a loop, the V-model mirrors each design stage with a test stage, and DevOps is a continuous cycle. Choose the pattern that matches how your team really works, not the one that looks best in a slide deck.

Waterfall process flow chart

A waterfall flow chart is a single vertical or horizontal line: requirements, design, implementation, verification, deployment and maintenance, each followed by an approval diamond. It works when scope is fixed and changes are expensive, and it makes contract milestones easy to show. Compare it with agile in our agile vs waterfall guide.

Agile and Scrum process flow chart

An agile flow chart puts the sprint at the centre as a loop: product backlog, sprint planning, development and testing inside the sprint, sprint review with stakeholders and a retrospective, then back to planning. Releases leave the loop whenever an increment is ready. The decision diamonds are “meets the definition of done?” and “ready to release?”.

V-model process flow chart

A V-model flow chart is drawn as a V: requirements, system design, architecture and module design run down the left side, coding sits at the bottom, and unit, integration, system and acceptance testing run up the right side. Dotted lines connect each design stage with the test stage that verifies it, which makes traceability visible. Our V-model guide explains when this structure pays off.

DevOps and CI/CD process flow chart

A DevOps flow chart is usually an infinity loop or a pipeline: commit, automated build, automated tests, security scan, deploy to staging, approval or automatic promotion, deploy to production and monitoring, with feedback flowing back to planning. Most of its steps are automated, so the boxes represent pipeline stages rather than people. See our CI/CD guide for how each stage is implemented.

How to Create a Software Development Process Flow Chart in 6 Steps

The fastest way to build an accurate flow chart is to map the process you actually follow today, with the people who do the work, and only then improve it. Drawing the ideal process first produces a diagram nobody follows.

1. Define the scope and the level of detail. Decide where the chart starts and ends (for example, “feature request” to “released to users”) and whether it shows the whole lifecycle or one stage such as testing.
2. List the steps with the people who do them. Run a 60-minute session with a developer, a tester, a product owner and whoever releases code. Write each activity on a card, in the order it really happens.
3. Add decisions and loops. For every approval or check, add a diamond with a “yes” and a “no” path. Draw where rejected work goes back to.
4. Assign lanes and owners. Group the steps into swimlanes by role, and make sure every step has exactly one accountable owner.
5. Mark inputs, outputs and tools. Note the artefact each step produces (ticket, build, test report) and where it lives, so handoffs are verifiable.
6. Validate, publish and review. Walk through a recent real feature on the chart, fix what does not match, then store the diagram where the team works (wiki, repository, project tool) and review it every quarter or after a major incident.

Keep one chart to a single page. If a step needs more detail, turn it into a predefined process and draw it in a separate chart; a security review or a release procedure usually deserves its own diagram.

Free Software Development Process Flow Chart Template (Mermaid)

The template below is a complete software development process flow chart written in Mermaid, a text-based diagram syntax that renders automatically in GitHub and GitLab Markdown and in most documentation tools. GitHub added native Mermaid rendering in February 2022, so the diagram can live in your repository next to the code and change through pull requests like any other file.

flowchart TD
    A([Feature requested]) --> B[Write user stories and acceptance criteria]
    B --> C{Requirements approved?}
    C -- No --> B
    C -- Yes --> D[Design: architecture, UX and UI]
    D --> E{Design approved?}
    E -- No --> D
    E -- Yes --> F[Develop and write unit tests]
    F --> G{Code review and CI passed?}
    G -- No --> F
    G -- Yes --> H[QA: integration, regression and performance tests]
    H --> I{Critical defects open?}
    I -- Yes --> F
    I -- No --> J[User acceptance testing]
    J --> K{Release accepted?}
    K -- No --> B
    K -- Yes --> L[Deploy to production]
    L --> M{Production healthy?}
    M -- No --> N[Roll back and fix]
    N --> F
    M -- Yes --> O([Released to users])
    O --> P[Monitor and collect feedback]
    P --> B

Copy it into any Markdown file inside a mermaid code block, rename the steps to match your team and add swimlanes with subgraph blocks if you need roles. For the documents that sit around this chart, such as the specification, test plan and release checklist, see our collection of software development templates.

Which Tools Can You Use to Draw a Flow Chart?

Any diagramming tool can draw a software development process flow chart; the right choice depends on whether the chart is a workshop artefact, a living document in the repository or a formal process standard. The comparison below covers the options teams use most in 2026.

A practical combination is a whiteboard for the mapping workshop, then a Mermaid version in the repository as the source of truth. That way the diagram is reviewed whenever the process changes, just like code.

Common Flow Chart Mistakes and How to Avoid Them

Most software process flow charts fail for the same reason: they describe an ideal that nobody follows, so the team stops looking at them. These are the mistakes we see most often in client and partner diagrams:

• Drawing the ideal instead of the real process: map what happens today first, then mark the target changes in a different colour.
• No loops back: a chart without “no” paths implies tests never fail and designs are never rejected.
• Too much detail on one page: more than 15 to 20 shapes usually means some steps belong in a sub-process chart.
• Steps without owners: a box that “the team” owns is a box nobody owns.
• Unlabelled decisions: every diamond needs a question and labelled exits.
• Mixing flow and data: put data movement in a separate data flow diagram so the process stays readable.
• Never updating it: review the chart quarterly and after every serious incident or process change.

How Should a Vendor’s Process Flow Chart Look When You Outsource?

When you outsource development, ask the vendor for their process flow chart before you sign, and check that it shows your approval points, the quality gates and how changes are handled. A vendor that cannot draw its own process on one page usually does not have a repeatable one.

Look for these elements in a vendor’s diagram:

• Your lane: where you approve requirements, review designs, attend demos and accept releases.
• Change requests: a clear path for new or changed requirements, with estimation and approval before work starts.
• Quality gates: code review, automated tests and QA sign-off before anything reaches you for acceptance.
• Release and rollback: who deploys, how production health is checked and what happens if a release fails.
• Support after launch: how incidents and bugs are reported, prioritised and fed back into the backlog.

Comparing two vendors’ flow charts side by side is often more revealing than comparing their slide decks. Teams that offer end-to-end product engineering should be able to show the whole loop, from discovery to monitoring, with named roles in each lane.

Frequently asked questions

Published 4 November 2026. Sources: ISO 5807:1985, documentation symbols and conventions for data, program and system flowcharts; ISO/IEC 19510:2013, Business Process Model and Notation (BPMN); GitHub Blog, Include diagrams in your Markdown files with Mermaid (February 2022).