Software Development Process

Summary

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

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

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.

 

term	description
IT	Information Technology
IT Department	Department in charge of computers
Process	Short for Software Development Process
Software Development Process	Topic of this article
No Process	Winging it
Best Practice	Widely accepted way of doing something
Software Development Lifecycle	Phases of a software project
	memorize

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 practice	description
Source code control system	Stores all source code versions
Project plan	Timeline of who will do what when
Requirements gathering	Figuring out what is needed, before coding
Unit testing	Developer tests for their own code
	memorize

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.

 

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

Software Development Life Cycle - Phase Summary

phase	summary
Requirements	Figuring out what the software should do
Analysis	Analysing/prioritizing requirements
Design	Planning what your code will look like
Implementation	Coding
Testing	Checking whether the sofware works
Deployment	Giving the software to your users
	memorize

 

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.

 

Term	Description
Business Analyist	Non-technical person dealing with requirements
Users	The people that will use your finished software
Use Case	Describes specific thing a user will do
Use Case Diagram	Stick figures, arrows, and ovals
Docs	Short for "Documents" or "Documentation"
Requirements Docs	Use cases or other documents that describe requirements
	memorize

 

A good example of a Use Case Diagram can be found http://en.wikipedia.org/wiki/Use_case_diagram.

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.