Part 2/2: What is a software development plan?

When using references, don't forget that they must be unique, i.e. the specific processes including the specific versions.

This list of results helps you check whether everything is complete and available before releasing the software. This allows you to quickly identify any gaps and evaluate or, of course, close them.

You have complete freedom, but make it clear and binding!

The procedure may look different for the source code, for SOUP elements and for tools.

You can refer to relevant processes or describe it specifically for the respective project.

Example:

• All source code for the project is managed in Subversion. Changes to the source code prior to Quality Gate 1 can be made directly by developers.
  Changes between Quality Gate 1 and 3 must be approved by the project manager.
  Changes after Quality Gate 4 must be approved by the Change Control Board.
•  SOUP elements are managed across projects in Clear Case. Changes to SOUP components are only implemented after checking dependencies on other projects.
• The development tools used are managed and controlled by central IT. Necessary updates to the development tools must be reported to central IT. The use of new versions is only permitted after successful approval by central IT.

List the SOUP components and development tools used in your plan and remember that it must be clear (see also chapter 5.1.4).

Describe the procedure in detail or refer to higher-level processes that describe the procedure.

As with change management, problem-solving can be approached differently depending on the project phase. The further your development progresses and the closer it approaches completion, the more formal your approach should be. Take advantage of the opportunity to define different approaches depending on the phase.

Example:

Problems with the development tools used can be resolved directly with central IT before Software Quality Gate 1. After Quality Gate 1, a ticket must be created and an initial risk assessment regarding the impact on the project must be performed.

After Quality Gate 2, problems must be escalated to the project manager.

As the name suggests, we're talking about a plan here. A plan is created at the outset. Therefore, the plan can't already contain everything in version 1. The plan is a living document. The standard even explicitly requires you to keep it up to date and adapt it to changing circumstances.

Include a reference to the system requirements in your plan, which are the basis for the software.

Don't forget to update your plan, including the references, if system requirements change. See also Section 5.1.2.

What could this look like in concrete terms?

To ensure that the software meets customer requirements, the following procedure is followed:

• The identified users receive a mock-up to review the user interface during development.
• The results are evaluated and incorporated into development planning.
• After successful verification, the identified users receive the software including near-production hardware.
• The results are evaluated and a decision is made as to whether the results will be incorporated into the product to be released or into a subsequent release.

This strongly aligns with configuration management. A complete configuration includes everything needed to uniquely and reproducibly identify a piece of software. This also includes the tools you use, standards, and the approach you take, such as verification methods.

Everything must be clearly identified, as all these points influence development and must be clarified.

The standard doesn't dictate how you integrate; it can be anything from a "big bang" approach to an "iterative" approach. However, make sure that the approach corresponds to the criticality of the project.

The approach to software integration depends heavily on your software architecture. Use this as the basis for your integration strategy!

You've now defined how you'll assemble your software. However, you haven't yet defined when you'll perform which tests!

For this reason, determine which tests you plan to perform during the integration.

This can look like this:

• -A functional integration test is carried out for the software units a,b,c and then the software units d,e are integrated.
• A load test is carried out for component x (consisting of the software units a,b,c,d,e).

You have a lot of freedom and therefore a lot of options. Define the optimal approach and make sure you then implement it as planned.

Please also note that you can combine the integration tests and the system tests, but you should, as always, plan and document this procedure.

Define everything that needs to be created, starting with the test specification, continuing with the design of the tests, through the execution of the tests, to the creation of test reports.

All these are results of verification activities that need to be planned.

For these results, you also need to define when you accept them. An acceptance criterion for a test specification would be, for example, that each requirement must have at least one test case, and the specified test methods must have been applied.

Define what needs to be available and at what time.

Verification planning is a very complex task. This activity is typically defined in one or more test plans (e.g., one test plan per level). These planning activities are often referred to as a "verification strategy."

In such a verification strategy, you can clearly describe the required points and demonstrate how you will proceed. A verification strategy is often found as a project-wide description for all projects. Any necessary details are then provided within the individual project.

If your product is a system with embedded software, software risk management will be part of the risk management of your overall system.

This starts with the software system specification, continues with the software architecture, test specifications, etc.

Identify all document types that are created and specify:

• What is the name of the respective document?
• What is the document intended for?
• Who is this document relevant for?
• How is the respective document created, released and modified and by whom (responsibilities)?

Configuration elements include all software modules or source code files, as well as SOUP components used. Furthermore, all documents created during software development or maintenance are considered configuration elements.

• Define what falls under version control
• Define the tasks and activities. For example, it may be necessary to first conduct a review and create a branch before putting something under version control.
• Define who is responsible (role). There can be multiple people responsible for different activities. Don't forget your IT department and their interface to ensure regular backups.
• Define when the components are to be added to the version control system. For example, you can require them to be added after each change and review.
• Of course, errors in configuration elements also occur. When do you proceed with the problem-solving process? Immediately after something is under version control, or only after a baseline has been established?

Consider the effort required depending on the definition chosen. Determine the appropriate approach for when you should start using the problem-solving process.

Everything you need to rebuild a software version needs to be versioned and controlled. This is the only way to ensure that you can recreate a specific software version at any time.

You will realize how important configuration management is when you receive feedback from the field.

The feedback must be investigated, the cause found, and you will be required to provide a clear statement about which software versions are affected by the potential bug.

So, first add the components to the version control system and specify the corresponding versions in your test reports! As mentioned in the previous sections, this doesn't just mean the source code, but everything you need to make verification reproducible. This starts with the specification, continues with the test specification, the tools used, and so on.

Always ask yourself whether you have everything under control so that you can repeat the exact test at a later date and get the same result.

Include all this information in your review!