Whilst browsing through answers on SO I came across something that is, in my view, one of the more frequent software development management misconceptions: "[software development] plan is a reasonably detailed description of all the activities you need to undertake".
Hence the question: what is good software development plan? Can it be boiled down just to a work breakdown structure; is WBS the single most important thing for a software development plan anyway?
Artifact: Software Development Plan
The Software Development Plan is a comprehensive, composite artifact that gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and is maintained throughout the project.
Software Development Plan contains
A Software Development Plan is a plan for how you will develop the software that you are inten upon developing and delivering.
While I know you young whippersnappers all think the military is a bunch of idiots, they in fact have a lot of experience in this area, and they, unlike a lot of commercial firms, put some thought into what had to be done. That included a bunch of very painful lessons on things that need to be taken into account, courtesy of projects that failed because those things were NOT considered.
I'm updating this on 10 April 2010. The DOD-STD-2167A source I previously listed has gone dark, so it makes sense to point you to MIL-STD-498 instead. Unfortunately, MIL-STD-498 was cancelled in 1998, and the DoD now expects contractors to use IEEE/EIA-12207 instead. IEEE standards, however, are not free as in beer.
See http://sepo.spawar.navy.mil/MIL-STD-498_DIDs/DI-IPSC-81427A_SDP.pdf for a Software Development Plan outline.
As you read the list of things that are required to be addressed, you might get the impression that some of those paragraphs are, like Navy regulations, written in blood. There's a reason for that impression: they are. Projects failed because they didn't address those areas in time.
See also http://sepo.spawar.navy.mil/SW_Standards.html: you can download a .zip with the standard and all the Data Item Descriptions (specifications for the individual documents).
(Yes, I'm aware that the DoD has moved away from DOD-STD-2167A, in favor of the IEEE commercial standards. However, IEEE charges an arm, a leg, and transplant rights on your left kidney for their standards. DOD standards are free as in beer.)
A Software Development Plan is a specific type of project plan. While a WBS is important, it is only scratching the surface.
A comprehensive project plan should have:
More information on each of these plans can be found in
The project Management Body of Knowledge.
For more specific guidlines, see Code Complete 2.
"[software development] plan is a reasonably detailed description of all the activities you need to undertake".
Which, generally, can't exist.
If you actually have all the requirements fully understood, and you have all the technology issues fully understood, you could write such a document.
If, however, you're doing something new -- something which the users do not already have installed -- or you are using any new technology, you cannot provide even a "reasonably" detailed description of the activities you need to undertake.
You can provide an overview, which will summarize some of what you need to do. But, as you explore the requirements, the users will discover things, learn, and change their mind. Revising the plan. As you explore the technology, the developers will discover things, learn, and revise the plan.
It can't be that hard -- people do this all the time.
The plan's audience is management. Managers want a "reasonably" detailed description of all the activities. As the users and developers learn about the requirements and the technology, the details change. This makes the "reasonable" test very, very hard to satisfy. When the details change constantly, what level of detail is "reasonable"?
Changes to the plan can (and do) arrive on a daily basis. Most managers won't want to make daily changes to the plan. So too much detail becomes "unreasonable". In order to create a plan that doesn't change very often, the plan actually needs to be a summary of activities. The only workable version of a "Software Development Plan" is a series of goals defined -- not in terms of activities -- in terms of functionality to be released to users.
In short, people do it badly all the time. In 30+ years of software development (much of it as a military subcontractor) there is a fantasy about planning that is simply not born out by the facts. Projects are cancelled with "reasonably detailed" plans, overly detailed plans and no plan at all.
Indeed, a plan is often the leading cause of cancellation. Why? With a "reasonably detailed" list of activities, any learning means the plan is wrong. Since the plan diverges from actual execution something must be wrong. Toss a coin. If you deem that execution is wrong, cancel the project for not following the plan. If you deem the plan is wrong, fix the plan to match the real world. The more detailed the plan, the more it seems "right" and the more likely to deem execution as faulty.
Bottom Line.
A Software Development Plan can be a fantasy document written as part of a "Waterfall" development methodology in which all kinds of things are over-specified up front and changes (from learning as the team progresses) is punished.
OR
A Software Development Plan is an Agile burndown chart that simply shows the sprints to be completed. The "reasonable" level of detail is actually quite low -- it's just a summary. And it changes during each sprint retrospective.
what i feel that in software developement project should be devided in two parts
In Project management all the extra possible things like company goal, project planning, project monitoring, estimation, Timesheet booking, defect tracking etc can be covered..
In project Developement, project Life cycle will be maintained like full waterfall