Artefacts in Software Development

In the preparation phase, an initial product backlog can be represented by means of a simple table.

Figure 6: Example of a GitLab Issue Board

A training session on how to use GitLab is available on ILIAS. 

Project Management Plan

The project management plan contains all information and decisions concerning the development process. The following subchapters describe the content of a good practice project management plan.
 

Vision and Goals

The project vision serves as the inspiration and provides focus for the project. It articulates the reason for the project in a short and understandable form, and it is important for the entire team to understand, share and work towards the same vision throughout the whole project.

A goal is a desired future state that is succinctly defined in terms of content, time, and extent. 
Together with the client/customer, try to formulate at least three but not more than six goals.

Goals should be formulated as «SMART» as possible. «SMART» stands for: 

• Specific  The goal must apply to concretely named organizations, framework conditions, etc.; the boundaries of the target area are specified.
• Measurable Qualities and, if necessary, quantities of goal achievement can be determined; indicators can be derived. 
• Appropriate Is it the “right” goal? Is there a need for the planned measures?
• Realistic The prospects of achieving the goal are sufficiently high under the given framework conditions (resources, time, skills); external, uncontrollable factors do not stand in the way of achieving the goal. 
• Time-bound A time frame is given.  

Deliverables  

Create a full list of artefacts the client/customer expects as the project team's output.

In a software development project, the main deliverable is the software itself. But clients/customers may wish to obtain documents describing the product, showing how the software was tested, helping them use the software, ….

Deliverables may be:

• Application software
• Software architecture documentation
• Test strategy and test script documentation
• User manual
• Deployment, installation, and maintenance manuals
• Project management plan

Clients/customers often wish to receive intermediate deliverables to start using parts of the new product as soon as possible (see chapter «roadmap»).  

The following table may be used to define the project deliverables:

Definition of Done

Next to the deliverables, define quality aspects the team must meet when implementing a backlog item. To do this, a “Definition of Done” is used.
 
In software, a Definition of Done may be: «Done means coded to standards, reviewed, implemented with unit Test-Driven Development (TDD), tested with 100 percent test automation (or according to the test strategy), integrated, and documented.»

Project Organization

Create a list of people involved or affected by the project (the stakeholders) and describe their role.
Set up the project team and define the tasks, competencies, and responsibilities of each team member. Define who from the project team assumes the role of the project leader, the scrum product owner, and the scrum master.

Roadmap

The roadmap is the long-term planning of the project and is used to check the economic efficiency.
It is based on the initial product backlog. It helps to allocate some extra time and capacity to the project duration and effort because it is well known that the initial product backlog often contains as little as 80% of all project requirements.
The roadmap’s key elements are called milestones.
A milestone is a planned point in the project process at which predefined, measurable (interim) deliverables are available and that facilitate the tracing of the project’s process and costs.
For each milestone, define which artefacts (see deliverables) must be available.
A milestone is reached once the required artefacts are available, and their review successful.

The roadmap for a bachelor’s thesis project with three milestones might look like this:

Figure 7: Roadmap example for a bachelor’s thesis project

Release Plan

The release plan in agile development is a short-term planning tool and states what is available after the next view sprints. It is based on the prioritized entries of the actual product backlog and shows which backlog items will be implemented in which of the following sprints.

The release plan can be a simple table or several issue boards in GitLab. 

Figure 8: Example of a release plan as a simple table

The release plan is a «living» plan. This means after each sprint, the release plan is updated, and the content of future sprints will be added.
For small projects, for example a bachelor’s thesis project, roadmap and release plan may be combined in one plan.

Risk Management

The purpose of risk management is to identify potential problems before they occur and to take actions and implement measures throughout the project’s life cycle to ensure that these problems do not occur and endanger the project objectives.

To identify risks, use checklists, brainstorm with stakeholders, and use experiences from previous projects.
Describe each risk and assess the probability of it occurring and its impact. For the highest risks (see risk matrix), identify indicators of occurrence and develop preventive action to mitigate the probability and/or corrective action to reduce the resulting damage. Next, try to estimate the effect of these actions.

To help gather all this information, you may use the following table.

Figure 9: Table used for risk management
To visualize the actual risk situation and the effects of your risk management actions, use risk matrices.

Figure 10: Risk matrices

It is important to check whether the risks recorded and described in risk management match those mentioned in the test strategy. The aim is to ensure that «risk-based testing» matches the project risks.

Controlling

Project control includes all activities to detect project-related deviations between the planned and actual status.
Possible reasons for deviations include:

• Changed or new requirements increase the project effort
• Inadequate effort estimation in sprint planning
• Misunderstood requirements
• Occurrence of risks
• Inefficient teamwork

There is a tool each to detect the deviations described above.

Changed or new requirements 
The project burndown chart shows the remaining amount of work as contained in the product backlog over time. The sprints are used as time ticks on the x-axis.
The trend line on the project burndown chart will generally trend downward. However, if new items are added to the backlog, then the total points remaining may go up.

Figure 11: Project burndown chart

In literature, the project burndown chart is often referred to as the release burndown chart. The term «release» is used to describe the deliveries for a milestone.

Inadequate effort estimation in sprint planning
To improve the team’s capacity to estimate its effort in sprint planning, use a simple table to compare estimations with actual effort for each sprint. Of course, it is necessary that each team member notes down the work done per task or user story to get actual value.

Project Support

The software architecture document describes all aspects of the product. 
A good structure to use this is described in the arc42 initiative by Gernot Starke, Peter Hruschka and Ralf D. Müller.
An overview of the arc42 software architecture document chapter structure of is given in the next figure (source: arc42 Template Overview, https://arc42.org/overview, called 11 August 2022).

Figure 13: Overview of the software architecture documentation's chapter structure according to arc42

The arc42 website https://arc42.org/ explains the structure used to construct, communicate and document the software architecture in detail.
In addition to a detailed explanation of the expected content of the various chapters, the website contains tips and real-life examples.