Software Development Processrename
Updated 2006-10-28 00:38
SummaryThis 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 termsFirst, let's get some basic terms out of the way.
ITIT (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.
ProcessProcess 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.
|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|
Which process is "right"?Not all advocates of process use the same steps and terminology.
Different StandardsIn 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 CompaniesNote 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 practicesSometimes 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|
Software Development Life CycleThe 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.
Software Development Life Cycle - Phase Summary
|Requirements||Figuring out what the software should do|
|Design||Planning what your code will look like|
|Testing||Checking whether the sofware works|
|Deployment||Giving the software to your users|
Note that sometimes the Requirements and Analysis phases are merged together into a single Requirements Analysis phase.
Requirements PhaseThe 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 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|
A good example of a Use Case Diagram can be found http://en.wikipedia.org/wiki/Use_case_diagram.
Analysis PhaseDeciding 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.