Before I go into the types of documents I use with my team, Let me go over each of the development paradigms (as well as some of their strengths and weaknesses.
Waterfall: In this paradigm, one creates *all* of the requirements needed for a project, provides the requirements to a programer, and the product ius developed and tested based upon the requirements.
Pros: Designed by DOD for use with contractors. This approach freezes the requirements allowing the developers to program according to a specification.
Cons: Inflexable to changes. Some studies have even suggested (NASA and NSF for example) that this paradigm leads to poor software since the users are not involved for most of the project. Additionaly clients do not know what they want until they see a mock up of the presentation. This approach requires a very short programming cycle.
General Thumb: As a contractor this paradigm is easy to manage since the requirements are set up front.
Iterative: This paradigm breaks up a project into more managemeable chunks. Requirements are checked to see if they match the current process model after each phase for quality control.
Pros: For bigger projects and an educated consumer, this development paradigm forces the end user to be engaged early and often. By bitting off smaller chunks, the project becomes successful since the milestones are easier to reach.
Cons: Requires a client that can communicate with the user group. Does not lend itself well to a contracting out approach unless the contractor guides all development. Also, like the waterfall paradigm, this approach does not build in useability from the onset. Adddtionally, this approach has a longer timeframe to complete the project, and requires strong project managers on both the IT and the program office.
Evolutionary Prototype: In this paradigm requirements and design are moulded into one. By collaberating with the client using wireframes and HTML mockups, the client can fully help in the building of the application -- and figure out the necessary steps. This approach lends itself well in conjunction with the iterative paradigm. FLiP, discussed in other post is a classic example of this paradigm.
Pros: Lend itself well to rapid application and web development.Forces useability as well as client buy in from the begining. In my experaance, the best approach since I can communicate the items a client must accomplish in the project timeframe.
Cons: Clients sometimes like to hand a document and tell the contractor to figure out the problem. Requires a very strong disipline, project management, and methodology to implement. IT representives must be kind, caring and firm at the same time, since the program office can sometimes drag the requirements phase when figuring out their prototype. Requires disipline durring testing and deployment.
There is another paradigm, Sprial used when creating commercial software wherte the requirements are gathered durring the development process.
Now to the documents:
Depending on how deep you want to go with this items it could be a few or many. If you're using CMM that number could easily be 100 once the policy documents are counted!
Here's the minimum you'll need.
*Preproject*
Proposal/Statement of Work
Project Planning/ Timeline
Resources chart
Status Report
*Project*
Requirements/ Software Development Blueprint/ Prototype specification
Object Model/ Data Model
Functional Testing plan
Load Testing
Technical Documentation
Training Plan/Demo
*Post Project*
Accounting Report
You can get away with less (and other on the list will say that you don't need all of the documentation), however, these templates will guide your team through the process of creating good software. As your team becomes bigger and more specilized, this will help your team focus one the task at hand.
Jeremy Brodie
Edgewater Technology
web: http://www.edgewater.com
phone:(703) 815-2500
email: [EMAIL PROTECTED]
>I'm starting to build a CF web application with a team of developers and
>we're wondering what methodology to use. I've read that an Iterative
>method is more suitable than the Waterfall methodology for CFMX apps. Is
>this the case? What are people using these days?
>
>Also, what sort of documentation should I be producing and can anyone
>point me to some examples?
>
>Thanks!
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
