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), ...
Code quality
Code quality is mostly concerned with non-functional aspects of code, and covers many aspects of code at various levels (lexical, syntactic, structural, ...). Some tools, like FindBugs, analyse (the meaning of) the code in search for typical programming errors, some, like CheckStyle check more superficial properties like adherence to a coding styles and compute metrics the may help improve the code, and some, like SonarQube integrate all of this with CI.
(Regression) Testing
The purpose of regression testing is to ensure that changes due to software enhancements, patches, configuration changes, etc. have not introduced errors.
See Testing skill and proficiency
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), ...
There is also a process of using strict issue tracking where code updates must be associated with an issue, code is updated if and only if there is a specified issue.
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).
Proficiency 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 (heard about), 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.
| Activity/Proficiency | Fundamental Awareness | Novice | Intermediate | Advanced |
|---|---|---|---|---|
| Code management | Fetching code samples and other material from a code repository prepared by others, and being aware of the flow. | Basic commands for committing, pushing and pulling, and understanding what merge conflicts are and how to handle them. | Versions, tagging and branching and merging. Forking and updating. | Deployment and releases. |
| Code quality | Using tools for automatic formatting and simple refactoring. | Use tools for defining coding style and formatting code accordingly, have basic refactoring skills and run code quality checking tools locally or as part of CI. | Code analysis like null analysis and code metrics. Introduction of static and dynamic code analysis methods and tools | Verification of safety and mission critical systems Introduction of model checking and formal methods |
| (Regression) testing | Running pre-made tests on their code and understanding the fundamental idea of testing code behavior. | Writing and running their own unit tests (not necessarily TDD). | Writing integration tests according to the test pyramid; using mocking frameworks. | Regression testing Model-based testing |
| Continuous integration | Using tools for automising the process of building, testing, and deploying software. | Using a build system for assembling a runnable application. | Unit and integration testing, driven by build system. | CI automation using a server. |
| Issue tracking | Use issues tracking system to report bugs (to some system they are using). | Use issues to manage requirements that drive development. | Kansan-like management | |
| Code review | Going through code with others, to improve/ensure quality. | Pull requests, for contributing fixes to other system. | Using code review within own process, to close issues. | |
| Agile Methods | Knowing about Scrum etc. | Experience with some tools/meetings | E.g. Scrum Master |
Similar approaches found online:
Programmer Competency Matrix - https://sijinjoseph.com/programmer-competency-matrix/
Staged introduction (proficiency mapped to semester)
| Activity/Semester | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|
| Code management | ||||||||
| Code quality | ||||||||
| (Regression) testing | ||||||||
| Continuous integration | ||||||||
| Issue tracking | ||||||||
| Code review | ||||||||
| Agile Methods |
Bachelor in Programming (Games|Apps)
| Activity/Semester | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|
| Code management | ||||||
| Code quality | ||||||
| (Regression) testing | ||||||
| Continuous integration | ||||||
| Issue tracking | ||||||
| Code review |
3 Comments
Arne Styve
Hi! I would also have added Code Quality (or "Continuous Code Quality") by using tools like Checkstyle (for Java) and SonarQube (https://www.sonarqube.org). These are tools that we (the lecturers) can fairly easily set up so that the code quality of the students work can be automatically tested. Especially SonarQube seams to be very good, since it not only points out your bad code, but also describes why the design/code is poorly written, and shows examples of bad ways and good/preferred ways of coding.
I have introduced Checkstyle this semester for my introductory course in OOP (ID101912 Objektorientert Programmering), and am planning to try to set up a SonarQube solution for next year in the same course.
Unknown User (hal)
I completely agree that code quality is important! There is some overlap with CI, since code quality metrics are often reported by CI systems. But I'm happy to have it as a separate activity/proficiency. Code refactoring could also be part of a code quality activity, since it is a mechanism for improving the quality. I've added this to the document, please comment.
Unknown User (hjelsvol)
Code quality, CI, and testing are overlapping, but I think it is useful to consider them separate skills and have therefore separated testing away from CI.