Software Development Process

Updated 2006-10-28 00:38


This page is meant to describe the Software Development Process to newbies.


It is an introduction to large software projects. I say "large" because an elaborate plan or process isn't usually necessary for smaller, simpler projects. If you're new to the corporate IT enviroment, you may be interested in the terms discussed here.

Basic terms

First, let's get some basic terms out of the way.


IT (or "I.T.") stands for "Information Technology". In most large companies, the department that is in change of computers is usually called the IT Department.


Process is typically used in conversation in place of software development process. It is often derogatorily said that various projects "don't follow any process" or "don't have any process" to mean that they wing it, rather than following best practices and paying attention to the software development lifecyle.


Click on one of the memorize links in the table below to commit these terms to memory.


ITInformation Technology
IT DepartmentDepartment in charge of computers
ProcessShort for Software Development Process
Software Development ProcessTopic of this article
No ProcessWinging it
Best PracticeWidely accepted way of doing something
Software Development LifecyclePhases of a software project

Which process is "right"?

Not all advocates of process use the same steps and terminology.

Different Standards

In fact, the recommendations of various groups, companies, and even process experts often differ widely. They can use disparate terms, merge certain terms together, or omit certain terms, concepts, and practices altogether. Various groups and standards (such as the Rational Unified Process, the Project Management Institute, and many others) have their own very specific definitions and terms.


This page tries to stay high-level and focus on the generally-used terms and their generally undestood meanings.

Different Companies

Note also that particular companies will have their own vocubularies around process, depending on which standards they favor, which process-related software packages they use (if any) or simply with which they have experience.


Even when considering a specific process standard, you may often find that it makes sense to not use certain parts of it for certain projects. Some companies are flexible regarding this, and some are more strict, preferring that their process is followed very closely for every project.

Tools and best practices

Sometimes the first questions someone will ask you when trying to figure out how well your company "follows process" will be about which tools you use, and which best practices you follow.


Some tools and practices that most large well-run projects use include these.


tool or practicedescription
Source code control systemStores all source code versions
Project planTimeline of who will do what when
Requirements gatheringFiguring out what is needed, before coding
Unit testingDeveloper tests for their own code

Software Development Life Cycle

The Software Development Process is often considered the most important part of the Software Development Process. To further confuse things, these two terms are often used interchangeably.


The first thing a newbie in the corporate IT environment might notice is people throwing around terms like Requirements, Analysis, and Design to refer to the different phases of a project. All of the phases taken together are generally called the Software Development Lifecycle.


The names (generally agreed upon) of the phases included are in the following table. Click "memorize" to memorize their order.


Phase 1Requirements
Phase 2Analysis
Phase 3Design
Phase 4Implementation
Phase 5Testing
Phase 6Deployment

Software Development Life Cycle - Phase Summary

RequirementsFiguring out what the software should do
AnalysisAnalysing/prioritizing requirements
DesignPlanning what your code will look like
TestingChecking whether the sofware works
DeploymentGiving the software to your users


Note that sometimes the Requirements and Analysis phases are merged together into a single Requirements Analysis phase.

Requirements Phase

The Requirements phase consists of figuring out what your Requirements are.


Requirements for a software project are descriptions of what the completed software should do when your project is finished. At the end of the requirements phase you'll usually have a documents containing the requirements, or "requirements docs". This will usually be mostly text, maybe some diagrams or screenshots, and use case diagrams.


This phase is often done largely by business analysts and other non-technical people, but can be the most important phase. If your requirements are wrong, it may not matter how good your design or implementation was.


Business AnalyistNon-technical person dealing with requirements
UsersThe people that will use your finished software
Use CaseDescribes specific thing a user will do
Use Case DiagramStick figures, arrows, and ovals
DocsShort for "Documents" or "Documentation"
Requirements DocsUse cases or other documents that describe requirements


A good example of a Use Case Diagram can be found

Analysis Phase

Deciding how important each requirement is, as well as how easy each requirement is to implement, can be very useful. Usually you'll want to do the stuff that is of high importance and low difficulty. Often it will be discovered that a feature is difficult to implement and not very important. Or it will be discovered that a requirement isn't possible at all.


These decisions are usually considered part of an Analysis Phase. Often, though, there will be no definite Analysis Phase, and they will be considered part of the Requirements Phase, or the Design phase.

Recent badges