Loading...
hidden

View Mobile version

Meta navigation

Startseite – Hochschule Luzern

Language selection and important links

  • Contents
  • Contact
  • Login
  • De
  • En
Search

Main navigation

School navigation

  • Engineering and Architecture
  • Business
  • Computer Science
  • Social Work
  • Art and Design
  • Music

Sub-navigation

  • Degree Programmes
  • Continuing Education
  • Research
  • International
  • Events
  • Campus
  • About us

Sub-navigation

Breadcrumbs

  1. Computer Science Computer Science
  2. Degree Programmes Degree Programmes
  3. Agile Software Development Agile Software Development
  4. Artefacts in Software Development Artefacts in Software Development

Artefacts in Software Development

As explained on the previous site «Tasks in Software Development», all information gathered and all decisions made must be recorded in an artefact. Instructions for typical software development artefacts can serve as guideline.

hidden

Product Backlog

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

Tabelle für das anfängliche Product Backlog
Figure 5: Table used for the initial product backlog
 
Later, a tool like GitLab may be used to track progress over the backlog items. The next figure shows an GitLab issue board (source: GitLab Docs, https://docs.gitlab.com/ee/user/project/issue_board.html, called 11. Aug. 2022)
Beispiel eines GitLab Issue Boards

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:

Tabelle zum festlegen eines Projekts

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:

 
Beispiel für Roadmap einer Bachelorarbeit mit drei Meilensteinen
Beispiel für Roadmap einer Bachelorarbeit mit drei Meilensteinen

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. 

Beispiel eines Release Plans als einfache Tabelle

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.

Tabelle für das Risikomanagement

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

Zwei Beispiele einer Risikomatrix

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.

Projekt-Burndown Chart

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.

Tabelle Rückblick Sprintaufwand
Figure 12: Sprint efforts retrospective

Reflect these results in the team (look at Retrospective)
Misunderstood requirements
At the end of a sprint, the team presents the outcome to the stakeholders in the framework of the sprint review. It can also adjust the product backlog to meet new objectives.
Report the findings of the sprint review for each sprint.

Occurrence of risks
Risks are monitored periodically as part of project controlling. If necessary, a risk analysis is carried out again, e.g., in the case of new backlog items or major changes in the project.
Report for each sprint traceable all changes in the project risk list.

Inefficient teamwork
The purpose of the sprint retrospective is to review how the past sprint went in terms of the people, relationships, processes, and tools involved.
Report the findings of the retrospective for each sprint.
 

Project Support

Describe (e.g., in the form of an installation instruction) how to set up the development environment. What tools, servers, databases, frameworks, and libraries are used for development and testing?
Outline the repository organization. Where is the repository and which file structure is used?
hidden

Software Architecture Documentation

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

Übersicht der Kapitelstruktur nach arc42 für ein Softwarearchitektur-Dokument

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.

  • Agile Software Development
  • Types of Projects
  • Tasks in Software Development
  • Artefacts in Software Development

Footer(s)

FH Zentralschweiz

Social media links

  •  Facebook
  •  Instagram
  •  Twitter
  •  LinkedIn
  •  YouTube
  •  Flickr

Contact

Logo Lucerne School of Computer Science and Information Technology

Lucerne School of Computer Science and Information Technology


Campus Zug-Rotkreuz
CH- 6343

+41 41 349 30 70

informatik@hslu.ch

Direct entry

  • A bachelor's degree –
  • A master's degree –
  • Prospective Students (Continuing & Executive Programmes)
  • Unternehmen & Institutionen
  • Media Relations
  • For Students
  • For Members of Staff

Quick link

  • People Finder
  • University Buildings & Campus Locations
  • News
  • Library
  • Events
  • Jobs & Karriere
  • Hiring Rooms
  • Blog

Static links

  • Newsletter
  • Data protection notice
  • Publishing Acknowledgements
Logo Swissuniversities

QrCode

QrCode
We use cookies on this site to give you the best browsing experience. By continuing to navigate this site or closing this banner you accept this use of cookies. For more information please visit our privacy policy.
OK