Policies Section
  1. Software Project Lifecycle
  2. Best Project Development Method
  3. Software Project Documentation Requirements
  4. Software Project Documentation Standards
  5. Project Planning Phase
  6. Functional Requirements Specification
  7. Project Charter
  8. Project Plan
  9. Project Analysis Phase
  10. Project Design Phase
  11. Project Development Phase
  12. Programming Standards
  13. Project Testing Phase
  14. Software Test Plan
  15. Project Implementation Phase
  16. Software Installation Manual
  17. Software Maintenance Plan
  18. Configuration Management Plan
  19. Users Guide
  20. Project Maintenance Phase
Policies Section

Best Project Development Method

This document discusses project development methods for software projects. This document could be applied to both hardware and software projects but focuses on software projects. Software projects are more likely to have their requirements change than most hardware projects. This change either happens over time or it happens as the users learn more about the project as they use the systems provided by the project.

It is obvious that you could debate the best project development model or method forever. Many experts will tell you that no project development model is perfect and that you should pick the best project development model based on the characteristics and needs of your project. For example, the size of the project will have a great influence on the project development model that should be used. Each project development model has its own advantages and also each one has disadvantages. There is obviously no right project model to choose. This page will help you decide how to plan your project based on some fundamental facts.

The Facts

To choose a project development model, there are some facts to keep in mind. These facts are:

  1. Whether you use an iterative or linear project model, your project will go through each of the project phases outlined in the waterfall process. These phases include planning, analysis, design, coding, testing, implementation, and maintenance.
  2. Each software project will have its requirements change.
  3. Feedback and the ability to make changes will be important or instrumental to the success of the project.
  4. The project must be properly documented in order to be successful.

Project Suggestions

  1. Provide for basic project functions - Put the functions of the phases of the waterfall process into your project since these tasks must be completed regardless of the project model used.
  2. Plan for change - The strengths of some of the iterative project models lies in the fact that these models plan for change.
  3. Use modular design - Keep the architecture modular to allow future changes to be easier to make.
  4. Limit the project scope - The iterative approach limits the scope of the project in the first iteration providing only basic functionality. Add fault tolerence and more detailed or additional features. Add security features from the start.

During the initial project planning phases the project managers and planners, including technical staff, should decide how to provide for maintenance and project creep after the initial iteration is complete. This should be incorporated into the change management plan, software maintenance plan, and software configuration management plan.

Conclusions

There is no ideal project management model for software projects. The success of your project will hinge upon your ability to plan for change, know when to limit the project scope, and make sure basic project functions are implemented regardless of the project model you choose. If you use the waterfall process as your software project model, plan for change from the beginning and address how change will be implemented in your software maintenance plan.

Because the project managment model is not necessarily the primary factor in the success of a project, this document will examine the tasks performed in each phase of a project from a linear project model perspective. This will be to help the reader understand project requirements and software documentation requirements from the project perspective. This document will outline software documentation requirements in light of the project management process.