Two questions come up at the start of almost every software project: "When will it be done?" and "Why is it taking so long?" Both are answered largely by how the project is run, in other words by the software development life cycle (SDLC), also called the software development process. Without a defined process, everyone imagines a different schedule, a different scope and a different meaning of "done." With one, you know from the start which stage you are in, what is expected from whom, and when the work will be delivered.
In this guide we explain what the software development life cycle is, its seven stages, how waterfall, agile and Scrum differ, how a sprint works, how to estimate a delivery date from sprint velocity, how continuous delivery (CI/CD) puts software into production safely, and which model suits which project. No technical background is needed; it is written for anyone who plans to commission or manage software.
What Is the Software Development Life Cycle (SDLC)?
The software development life cycle is the working order that defines which stages a piece of software goes through from idea to production and on to maintenance, what is produced at each stage and who is responsible. The English name is Software Development Life Cycle, shortened to SDLC.
A process is not paperwork. It answers three questions: What are we building, and why? In what order and with what output do we move forward? How do we know a stage is finished? When these three answers are written down, the business side and the development team look at the same picture; otherwise the project depends on people's memory and goodwill.
What Are the Stages of the Software Development Life Cycle?
The software development life cycle has seven stages: planning, requirements analysis, design, development, testing, release and maintenance. Names vary a little between sources, but the job is the same: decide what to build, design how to build it, build it, verify it, put it live and keep it running.
| Stage | What happens? | Output |
|---|---|---|
| 1. Planning | Goal, feasibility, scope, budget and a first outline of the schedule | Project definition, initial scope |
| 2. Analysis | User roles, the current process, requirements and acceptance criteria | Requirements document |
| 3. Design | Screen and flow design, architecture, data model, integration design | Prototype, architecture document |
| 4. Development | Coding, unit tests, code review, integrations | Working pieces of software |
| 5. Testing | Functional, performance, security and acceptance tests; bug fixing | Test report, approved version |
| 6. Release | Going live, data migration, training, rollback plan | Live system |
| 7. Maintenance | Monitoring, bug fixes, updates, new features | New versions |
Each stage is its own field of expertise and could fill a guide of its own; we have covered several of them in separate articles. You can find the steps of requirements analysis in how to do software requirements analysis, the project plan and critical path in how to create a project plan, testing in how to do software testing and the budget in how to estimate software development cost.
We recommend reading: Our project process: step by step from analysis to go-live
What Are Software Development Models?
A software development model decides in what order and in what pieces the seven stages are carried out. The waterfall model runs the stages in sequence, once. Agile models repeat the same stages in short cycles, many times, for small pieces of the product. Continuous delivery automates the release and makes those cycles even more frequent.
| Topic | Waterfall | Agile (Scrum, Kanban) | Continuous delivery (CI/CD) |
|---|---|---|---|
| Structure | Stages in sequence, once | Short cycles, every stage in every cycle | Every change is tested automatically and prepared for release |
| Delivery | One big delivery at the end | A working version at the end of each cycle | Small releases daily or more often |
| Adapting to change | Hard; change is expensive | Easy; priorities are reordered each cycle | Very easy; small steps, fast rollback |
| Customer involvement | At the start and the end | A review in every cycle | Continuous feedback and measurement |
| Documentation | Heavy, up front | As much as needed, lightweight | Automation documents itself |
| Best suited to | Fixed, clear requirements; no changes expected | Requirements that become clear over time; valuable feedback | Products that are released often and run live |
The agile approach rests on the Agile Manifesto, published in 2001. It values working software over comprehensive documentation, collaboration with the customer over contract negotiation, and responding to change over blindly following a plan. That does not mean plans and documents are unnecessary; it tells you where the priority lies.
In real life most projects do not follow a pure model. A hybrid structure, which frames scope and budget up front in the waterfall way and then develops in agile cycles, is the most common choice, especially in corporate projects that need a fixed budget and a fixed delivery date.
How Does Scrum Work?
Scrum is an agile framework that splits work into short, fixed-length cycles called sprints. At the end of each sprint there is a usable, tested piece of software. According to the Scrum Guide, a sprint lasts at most one month; most teams work with two-week sprints.
- Roles: The Product Owner decides what will be built and in what order (representing the business side). The Scrum Master makes sure the process works and removes obstacles. The Developers design, code and test the work.
- Product Backlog: The list of all the work to be done, ordered by priority. Items at the top are detailed; items at the bottom are rough. User stories live here.
- Sprint Planning: The team selects from the top of the Product Backlog as much work as it can complete in that sprint.
- Daily Scrum: A stand-up synchronization of at most 15 minutes: what did I do yesterday, what will I do today, what is blocking me?
- Sprint Review: The working software is shown to the Product Owner and stakeholders; feedback goes back into the Product Backlog.
- Sprint Retrospective: The team discusses its own way of working: what did we do well, what will we change?
The strength of Scrum is that it brings information in early. The customer sees the software every two weeks; a misunderstanding is caught in two weeks, not in two months.
How Do You Estimate a Delivery Date from Sprint Velocity?
In agile projects the delivery date is estimated from how much work the team finished in past sprints. This rate is called team velocity, and it is the average amount of work (usually story points) completed per sprint. The formula is simple: Number of sprints needed = Remaining work ÷ Team velocity.
Example (the numbers are illustrative): A team completed 21, 24 and 27 points in its last three sprints; the average velocity is (21 + 24 + 27) ÷ 3 = 24 points. The remaining work in the Product Backlog is 120 points. The number of sprints needed is 120 ÷ 24 = 5. If the sprints are two weeks long, the estimated delivery is 10 weeks.
It is more honest to give the estimate as a range than as a single number. With the lowest velocity (21) you get 120 ÷ 21 ≈ 5.7, so 6 sprints (12 weeks); with the highest (27) you get 120 ÷ 27 ≈ 4.4, so 5 sprints (10 weeks). The right sentence is "between 10 and 12 weeks." New information arrives in every sprint, so the estimate is updated too; the remaining work is recalculated every sprint and shared with the Product Owner.
What Are Continuous Integration and Continuous Delivery (CI/CD)?
Continuous integration (CI) means developers merge the code they write into a shared repository often, and automated builds and tests run on every merge. Continuous delivery (CD) means a version that passes the tests is prepared for release automatically, and often put live with one click or fully automatically. Together they are called CI/CD.
The benefit for a business is this: a release stops being a dreaded, rare and long event and becomes a small, frequent and reversible routine. When a bug appears, it is easy to find which change caused it and to return to the previous version. The common parts of CI/CD are:
- Version control: The full history of the code is kept; who changed what and when is always known (usually with Git).
- Automated testing: Unit and integration tests run on every change, so whatever breaks is seen immediately.
- Separate environments: Development, test and production are kept apart; real customer data is not moved into the test environment.
- Rollback plan: If a release causes trouble, you can quickly return to the previous working version.
- Monitoring: Errors and performance are watched after release, so problems are noticed before customers complain.
Which Model Suits Which Project?
Three questions decide the choice of model: How clear and fixed are the requirements? How involved can the customer be in the process? How much change is expected? If the requirements are clear and will not change, choose waterfall or a hybrid; if they will become clear over time and feedback is valuable, choose agile; for live products that need frequent releases, continuous delivery comes to the front.
| Situation | Suitable approach | Why? |
|---|---|---|
| Scope fixed by law or contract, no changes expected | Waterfall or hybrid | Scope and delivery are binding from the start |
| A new product, user needs not fully known | Agile (Scrum) | You learn and correct course in every sprint |
| An internal system, clear process but many modules | Hybrid: framework up front, delivery piece by piece | The budget is predictable, risks show up early |
| A live web product that keeps evolving | Kanban and CI/CD | Small tasks flow, releasing is routine |
| A small, short job (a few weeks) | Lightweight agile: short analysis, weekly demo | A heavy process would be bigger than the job |
We recommend reading: Off-the-shelf or custom software? A decision guide
What Are the Common Mistakes in the Software Development Process?
The most common mistakes are skipping analysis and going straight to code, keeping the customer out of the process, leaving testing to the end, choosing a model by its name instead of the reality of the project, and leaving maintenance out of the budget.
- Skipping analysis: Analysis cut short with "let's start fast" turns into an expensive rewrite in the middle of the project.
- Lack of customer involvement: Working agile requires the customer to take part with someone who can decide in every sprint. A Product Owner who does not respond stops even the best process from working.
- Leaving testing to the end: The later a bug is found, the more expensive it is to fix. Testing should be part of every stage and every sprint.
- Lack of planning under the name of "agile": Agile does not mean working without a plan; it means updating the short-term plan often. A Product Backlog, priorities and acceptance criteria are still needed.
- Expanding scope without control: Every new request is a work item; it should not be added before its effect on scope, time and budget is discussed.
- Forgetting maintenance: Software is not finished when it goes live. Budget and an owner for security updates, backups, monitoring and new versions should be set from the start.
We recommend reading: How to back up business data? RPO, RTO and the 3-2-1 rule
How Can You Contribute to the Software Development Process?
The party commissioning the software is a partner in the process, not a spectator. The project speeds up when decisions are made quickly, content and data are ready on time, and feedback at every demo is clear and comes from a single source. Five habits are enough:
- Appoint a single decision maker: Everyone should know from the start whose word sets the priorities.
- Involve the users: The people who will use the software should attend the demos; an executive summary cannot replace the users' reality on the ground.
- Give feedback in writing and be specific: Instead of "I don't like it," write "this screen is missing this information."
- Do not let preparations slip: If texts, product data, account details and integration access arrive late, the release is late even when the software is ready.
- Agree on acceptance criteria in advance: If the definition of "done" is written down from the start, there is no argument at delivery.
We recommend reading: What Is Custom Software? Types, Examples, Advantages and Which Businesses It Suits
We recommend reading: What Is a Software Maintenance and Support Agreement (SLA)? Scope, Response Times and Fees
Recommended reading: What is microservices architecture? Monolith difference, cost and decision guide
Recommended reading: What Is Technical Debt?
The Software Development Process with İnovabil
At İnovabil we follow the same path in every project: analysis, design, development, testing, release, maintenance and support. In analysis we listen to your business and your users and turn scope, work items and schedule into a written proposal. In design we review the screen flows and a clickable prototype with you before any code is written. We move development forward in pieces (sprints), show the working version in regular demo meetings and back it with code review and automated tests, so you start seeing the first working version before the project ends. We stay by your side through testing, release, and the updates and support after release.
You can find our process steps on our process page and the work we have done on our projects page. Describe your project's scope, who will use it and the schedule you expect in a few sentences, and let us decide together which process model suits you.
Frequently Asked Questions
What is the software development life cycle (SDLC), in short?
The software development life cycle is the working order that defines which stages a piece of software goes through from planning to production and maintenance, what is produced at each stage and who is responsible. The stages are usually planning, analysis, design, development, testing, release and maintenance.
Is agile or waterfall better?
Neither is better in every case; it depends on the nature of the project. If the requirements are clear and fixed, waterfall or a hybrid fits; if the requirements become clear over time and feedback is valuable, agile fits better. Many corporate projects use a hybrid structure that outlines the framework up front and runs development in agile cycles.
What is Scrum, and how long should a sprint be?
Scrum is an agile framework that splits work into short, fixed-length cycles called sprints. According to the Scrum Guide, a sprint lasts at most one month; most teams use two-week sprints. At the end of each sprint there is a working, tested piece of software.
How is the delivery date set in an agile project?
The team's average velocity over past sprints (points completed per sprint) is measured; dividing the remaining work by that velocity gives the number of sprints needed. The estimate is given as a range rather than a single number and is updated every sprint. For example, 120 points of work at a velocity of 24 points takes 5 sprints, or about 10 weeks with two-week sprints.
What does CI/CD bring to software development?
Continuous integration and delivery means code is merged often and tested automatically, and a version that passes the tests is released with confidence. A release stops being a rare, risky event and becomes a small, frequent and reversible routine. Finding and fixing bugs also gets faster.