Are you still planning or are you already developing?
There's a lot of discussion about why a software development plan is even necessary. Almost no one would think of starting a major project without a plan. Who builds a house without a plan? Who goes on vacation without one? There are plenty of examples where each of us creates a plan to achieve a certain goal, either written down or just in our heads!
The software development plan is one of the central documents in software development. As the name suggests, it is a plan.
A plan / planning is according to Wikipedia (https://de.wikipedia.org/wiki/Plan) "the representation of a future sequence of actions." This also clarifies when a plan is created.
At the beginning of a project and not at the end, in order to meet the normative requirements!
A plan describes how, i.e. with which activities and with which means, a specific goal is to be achieved.
What do you do if you notice that the circumstances or destination of your trip have changed? That's right, you update your plan and adapt it to the new circumstances.
It's no different with a software development plan. Create the first version at the beginning of a project and don't be afraid to adapt the plan if necessary.
This is also required by 62304 in Chapter 5.1.2 “Updating the Software Development Plan”.
I've often experienced a plan being created once and never updated. When you reach the end of the project and want to check whether everything was done according to plan, you realize that things that were planned haven't been implemented.
When asked, you'll be given many reasons why a different approach was taken during the project. These reasons often make perfect sense, but unfortunately, no one thought to update the plan.
So remember: A plan isn't set in stone; it's a living document. If an update is necessary, then do it!
The software development plan is intended to facilitate professional, planned, and structured software development, as well as to manage and review it. It's about considering how the software should be developed early on, managing it accordingly, and ensuring that everything has been completed by the end of a project.
The software development plan describes the concrete approach for a project.
At the beginning of the voyage (the project), the course to be taken is determined. During the voyage, the course is continuously monitored. Either the ship's course is corrected if it deviates from the planned route, or the planned route (the plan) is adjusted if conditions change, e.g., a storm is approaching.
In Chapter B.5.1, the 62304 also clearly expresses what it sees as the purpose of planning:
“Planning software development tasks to minimize the risks caused by software.”
The plan should also serve as a means of communication for the members of the development team and thus help to achieve appropriate software quality.
The 62304 also gives the manufacturer a lot of freedom, whether there's a single software development plan for all projects or a separate plan for each project. It's up to you to decide!
The level of detail depends on the risk. This means that if you're developing high-risk software, the planning should be very detailed and precise to minimize risk.
You can compare it again to planning a sea voyage. If you're planning to sail across the North Atlantic, passing close to icebergs, you'll need to plan in much greater detail and precision than if you're sailing from Italy to Greece.
The software development plan has another nice effect.
Don't you often get asked by management where we are in the project, are we on the right track?
Bad, if you don't have a concrete plan, how are you supposed to know where you stand and communicate that?
With a software development plan, you can shine. You show the planned activities, you signal that you have your project under control and you can also clearly show what was planned and where you currently stand!
Your management will be thrilled with so much structure and overview!
Now that it is hopefully clear what a software development plan is and why it is needed (not only for normative requirements), I will describe in the second part of this article what a software development plan can look like in concrete terms.