• Created by Unknown User (hjelsvol), last modified by Unknown User (hal) on 10.02.2017

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Software Development Management Tools Working Group

This working group has a shared interest in tools being used for managing a SW development project - including tools for version control, issue tracking, documentation, etc.

Members

  • Arne Styve
  • Hallvard Trætteberg
  • Michael Tollefsen
  • Rune Hjelsvold
  • Simon McCallum

Classes of activities/tools

Code management (including version control)

A code repository provides the possibility to share code, create versions (time- and tag-based) and branches (topic-based). There are typically two levels of organisation: repositories and organisation (often called group or project). The repository is where the code is stored, and any user will typically be able to create new repositories and grant other uses access. An organisation may be defined as the owner of several repositories, so they can be more easily managed by the organisation. E.g. a course (emne) may the organisation which manages repositories, one for each student project group.

Examples are git and mercurial (core systems), github (cloud provider), gitlab (software and cloud provider), Stash/Bitbucket from Atlassian (software and cloud provider), ...

Continuous integration (CI)

CI is a general term for building, testing and deploying the system you are developing, mainly to ensure it's quality, but also to automatically roll out new versions. CI is often automated by tools like ant, maven and gradle. These tools can be run locally, and/or on specialised servers that run build jobs on server farms. The advantage is both making builds independent of the individual developers and scaling to large systems. The build jobs may be triggered manually or automatically, when new code is committed and pushed to a code repository.

Examples of systems are Jenkins and Hudson (standalone), Travis (cloud provider), gitlab (integrated), Bamboo from Atlassian (software and cloud provider), ...

Issue tracking

Issues are a way of managing development tasks based on requirements spanning from feature requests to bug reports. Issues can be entered by both developers, e.g. as a feature to develop in a sprint, or users, e.g. as feature requests or bug reports. Issues typically go through phases and may are assigned to people. Branches and commits often refer to issues.

Systems for issue tracking may be both integrated and standalone. Examples are github and gitlab (integrated), Jira from Atlasssian (standalone, but integrated with other Atlassian products), bugzilla (standalone), ...

Code review

When providing code for an issue, you often want to review it before allowing the code to be committed into and merged with the code repository. This is particularly relevant when code is contributed from outsiders, like in open source projects, but also relevant in more closed settings, to ensure quality. Sometimes you also want to run CI on the code, before doing the review and stamp of approval.

Examples of systems are git (supports so-called pull requests where a branch in a fork is contributed to the main project), gerrit (hosts a copy of a repo and can run CI on it before changes are merged into the main repo).

 

Maturity levels

If we want to introduce these activities in a curriculum in a study program, we should consider a staged approach, were activities and tools are introduced gradually. Based on proficiency levels (https://hr.od.nih.gov/workingatnih/competencies/proficiencyscale.htm: Fundamental Awareness, Novice (limited experience), Intermediate (practical application), Advanced (applied theory), Expert (recognized authority)). For a bachelor program, we may expect students to reach a Intermediate level in some activities, and Novice in others, while a master program may lift the bar depending on the specialisation.

Level 0:

  • Fundamental Awareness of Code management, like fetching code samples and other material from a code repository prepared by others.
  • Fundamental Awareness of Continuous Integration, by running pre-made tests on their code.

Level 1:

  • Novice in Code management, share code within a group by setting up a repository and using basic commands for committing, pushing and pulling.

 

  • No labels