Propose a software plan In your proposal, you must state the software developmen

Question

Propose a software plan In your proposal, you must state the software development project that will be the topic about software used to assign social security number to population, Software Development Plan. The (DR Congo) needs software to help with (Identify population demography ). For my software development project, I will create a Software Development Plan document for software that will have the following functionality:

1 - functionality A_ Assigning population for unique social security number

2 - functionality B- Identifying number of Congolese Population

3 - functionality C- be able to background check from the security number

4- functionality D – assigned people with an ID number

Explanation / Answer

he 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.

Related Questions

Navigate

• Browse (All)
• Browse P
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.