Since the first programmable computers, software developers and managers have struggled with fundamental problems in executing a project from inception to deployment. After nearly 65 years, most of the same breakdowns still remain. In fact, the Standish group reports that over 80% of projects are unsuccessful either because they are over budget, late, missing function, or a combination. Moreover, 30% of software projects are so poorly executed that they are cancelled before completion. In our experience, software projects using modern technologies such as Java, J2EE, XML, Visual Studio and Web Services are no exception to this rule. This article contains a summary of best practices for software development projects.
1. Development Process
It is important to choose the appropriate development lifecycle for a given project because all other activities are derived from this process. A couple examples of this are the Rational Unified Process (RUP) and the extreme Programming (XP) methods. Having a well defined process is usually better than having none at all, and in many cases it is less important what process is used than how well it is executed. The methodologies above are very common and a quick Web search will turn up all kinds of information regarding how to implement them.
Gathering and agreeing on requirements is fundamental to a successful project. This does not necessarily imply that all requirements need to be fixed before any architecture, design, and coding are done, but it is important for the development team to understand what needs to be built. Quality requirements are broken up into two kinds: functional and non-functional. A good way to document functional requirements is using Use Cases. Note that Use Cases are used for non-OO projects. A definitive book on the subject of use cases is by Armour and Miller. Non-functional requirements describe the performance and system characteristics of the application. It is important to gather them because they have a major impact on the application architecture, design, and performance. See the non-functional requirements checklist on the Construx Web site.
Choosing the appropriate architecture for your application is key. You have to know what you are building on before you can start a project. Check the architecture of the target. Read as much as you can about the ins and outs of the platform and note any pitfalls before you start your code. It will go a long way to heading off any bugs that might be 'show stoppers' later on.
Even with a good architecture, it is still possible to have a bad design. Many applications are either over-designed or under-designed. The two basic principles here are "Keep it Simple" and information hiding. For many projects, it is important to perform Object-Oriented Analysis and Design using UML. Code reuse is but one form of reuse and there are other kinds of reuse that can provide better productivity gains.
5. Code Building
Building the code is really just a small part of the total project effort even though it's what most people equate with the whole process since it's the most visible. Other pieces equally or even more important include what we have already gone over the above namely requirements, architecture, analysis, design, and testing. A best practice for building code involves daily builds and testing.
6. Peer Reviews
It is important to review other people's work. Experience has shown that problems are eliminated earlier this way and reviews are as effective or even more effective than testing. Any artifact from the development process is reviewed, including plans, requirements, architecture, design, code, and test cases. Peer reviews are helpful in trying to produce software quality at top speed.
7. Software Testing
Testing is an integral part of software development that needs to be planned. It is also important that testing is done proactively; meaning that test cases are planned before coding starts, and test cases are developed while the application is being designed and coded.
8. Performance Testing
Testing is usually the last resort to catch application defects. It is labor intensive and usually only catches coding defects. Architecture and design defects may be missed. One method to catch some architectural defects is to simulate load testing on the application before it is deployed and to deal with performance issues before they become problems.
9. Configuration Management
Configuration management involves knowing the state of all artifacts that make up your system or project, managing the state of those artifacts, and releasing distinct versions of a system. There is more to configuration management than just source control systems, such as Rational Clearcase.
10. Quality And Defects Management
It is important to establish quality priorities and release criteria for the project so that a plan is constructed to help the team achieve quality software. As the project is coded and tested, the defect arrival and fix rate can help measure the maturity of the code. It is important that a defect tracking system is used that is linked to the source control management system. For example, projects using Rational ClearCase may also use Rational ClearQuest. By using defect tracking, it is possible to gauge when a project is ready to release.
Deployment is the final stage of releasing an application for users.
12. System Operations And Support
Without the operations department, you cannot deploy and support a new application. The support area is a vital factor to respond and resolve user problems. To ease the flow of problems, the support problem database is hooked into the application defect tracking system.
13. Data Migration
Most applications are not brand new, but are enhancements or rewrites of existing applications. Data migration from the existing data sources is usually a major project by itself. This is not a project for your junior programmers. It is as important as the new application. Usually the new application has better business rules and expects higher quality data. Improving the quality of data is a complex subject outside the scope of this article.
14. Project Management
Project management is key to a successful project. Many of the other best practice areas described in this article are related to project management and a good project manager is already aware of the existence of these best practices. Our recommended bible for project management is Rapid Development by Steve McConnell. Given the number of other checklists and tip sheets for project management, it is surprising how many project managers are not aware of them and do not apply lessons learned from previous projects, such as: "if you fail to plan, you plan to fail." One way to manage a difficult project is through timeboxing.
15. Measuring Success
You can measure your development process against an industry standard known as the Capability Maturity Model (CMM) from the Software Engineering Institute at Carnegie Mellon University. Most projects are at level 1 (initial). If you implement the best practices described above and the guidelines in the companion article, Guide to Running Software Development Projects, then you could be well on the way to achieving a higher maturity level and a successful project.
This article provided a list of best practices that help improve the success of a software development project. By following these best practices, you have a better chance of completing your project successfully.
- 31st March, 2009: Initial post