Suggest changes to SE skills section

.github/spellignore.txt

@@ -94,6 +94,7 @@ HTC
 IDEs
 Ing
 ISCB
+iteratively
 Jena
 JOSS
 JU

.github/workflows/spellcheck.yml

@@ -37,6 +37,6 @@ jobs:
             yq '.authors[] | .suffixName' contributors.yml | sed 's/ /\n/g; /null/d' >> .github/spellignore.txt
       - uses: eschercloudai/[email protected]
         with:
-          files-to-check: "competencies.md|call_to_action.md|survey.md|institutionalised_education.md|intro.md"
+          files-to-check: "competencies.md|call_to_action.md|survey.md|institutionalised_education.md"
           files-to-exclude: "CONTRIBUTING.md\nREADME.md"
           words-to-ignore-file: .github/spellignore.txt

competencies.md

@@ -187,7 +187,7 @@ We start with a non-exhaustive overview of existing initiatives in @sec:related-
 provide the guiding principles for the work of an RSE.
 @sec:required-generic-skills defines a set of core skills based on these values.
 The skills themselves fall into three categories, namely
-"software engineering", "research", and "communication" skills,
+"software/technical", "research", and "communication" skills,
 reflecting the hybrid nature of an RSE.
 To justify the selection of these skills,
 we also list some current tasks
@@ -380,7 +380,7 @@ The role of an RSE lies somewhere on the spectrum between that of a researcher
 (the "R") and a software engineer (the "SE") and, therefore, requires
 competencies in both fields. RSEs typically apply their knowledge and
 experience in larger teams which allows them to cultivate this hybrid nature.
-Therefore, we categorise the competencies into three categories: *software engineering skills*,
+Therefore, we categorise the competencies into three categories: *software/technical skills*,
 *research skills*, and *communication skills*, with a particular focus on the software and
 research cycle and the scientific process. These competencies are relevant in a
 broad setting and form the foundation for specific specialisations.
@@ -396,19 +396,36 @@ and competencies also depends on the size of the RSE team
 (**Project team size**). Finally, different sets of skills are emphasised in
 the different RSE specialisations (**RSE specialisations**).
 
-## Software engineering skills
+## Software/Technical skills
 
 \newcommand{\skillsection}[1]{\hypertarget{skills-#1}{%
 \subsubsection{\glsentrydesc{#1} (\texorpdfstring{\glsentrytext{#1}}{#1})}\label{skills-#1}}}
 
-There are many \ac{SE} curricula out there, that try to define
-which tasks a software engineer should be able to perform. A recent example
-highlighting some aspects in more detail than here is @Landwehr2017.
-The software skills outlined here are required to make research software adhere
-to the \ac{FAIR} principles, which are aspects of good scientific practice.
-@ChueHong2014 defines different levels of research
-software reusability and the extent to which the \ac{SE} skills
-need to be applied to reach them.
+The technical skills required by an RSE overlap to a large extent with the common 
+fundamental software engineering skills (see, e.g., @Landwehr2017), but put greater
+emphasis on aspects related to achieving good scientific practice. 
+For example, RSEs need to know how to make research software adhere to the 
+\ac{FAIR} principles, and how to achieve different levels of research
+software reusability @ChueHong2014. To reflect this, the technical skills
+listed below complement competencies regarding the standard life-cycle of 
+software development with RSE-specific focus skills. 
+
+
+<!-- Adapting to the software life-cycle -->
+\skillsection{SWLC}
+
+The traditional software development life-cycle defines the stages that form the process of building a piece of software.
+Initial development generally involves an analytic process where needs and ideas are gathered and analysed (requirements engineering),
+followed by a formulation of a plan to fulfil them (design) that is finally turned into running code (implementation).
+This is accompanied by different measures of quality control (e.g., reviews, testing), validating and verifying 
+that things work as expected and that they continue to do when development progresses further. Depending on the software project, this can mean a simple "Think-before-you-do", or more elaborate and formal processes.
+Often the development cycles are executed iteratively and incrementally.
+The life-cycle further includes periods of deployment, maintenance and further development (software evolution), 
+as well as software retirement.
+Additionally, the research software life-cycle extends the traditional life-cycle
+with \gls{software-publication}. The RSE should be aware of this life-cycle
+and be able to predict and cater to the changing needs of a software project as it moves through the stages.
+
 
 <!-- Creating documented code building blocks -->
 \skillsection{DOCBB}
@@ -449,14 +466,15 @@ and be able to predict and cater to the changing needs of software as it moves t
 <!-- Use repositories -->
 \skillsection{SWREPOS}
 
-The RSE should be able to identify and use fitting public platforms (so-called software repositories or repos) to share the artefacts they have
-created and invite the public to scrutinise them for public review.
+The RSE should be able to identify and use fitting public platforms (so-called software repositories or "repos")
+to share the artefacts they have created and invite the public to scrutinise them in public reviews.
+
 
 <!-- Software behaviour awareness and analysis -->
 \skillsection{MOD}
 
 We define this as a certain quality of analytical thinking that enables an RSE to
-form a mental model of a piece of software in a specific environment.
+form a mental model of a piece of software in a specific environment (program comprehension).
 Using that, an RSE should be able to make predictions about a software's behaviour.
 This is a required skill for common tasks such as debugging, profiling, optimising, designing good
 tests, or predicting user interaction.
@@ -671,10 +689,10 @@ A story-like example of an individual through the hierarchies can be found in @s
 
 | Competency | Junior RSE                                                                                                                    | Senior RSE                                                                                                                            | Principal RSE                                                                                                                                                                       |
 | ---        | ----------                                                                                                                    | ----------                                                                                                                            | ----------                                                                                                                                                                          |
+| \gls{SWLC}       | Should be aware of the software life-cycle.                                                                                   | Should know where in the life-cycle their project is and which decisions are likely to lead to technical debt.                        | Should know how to manage and steer development/project resources accordingly. Should also have an understanding of the potential consequences of key project management decisions. |
 | \gls{DOCBB}      | Should be able to write reusable building blocks.                                                                             | Same as junior, but the quality should set the standard for the project, while following current best practices.                      | Should know the current best practices and point their staff to the right resources.                                                                                                |
 | \gls{LIBS}       | Should be able to use package distribution platforms.                                                                         | Same as junior, but should also be familiar with current best practices for building and deploying packages.                          | Should ensure that their project is available via an up-to-date and secure distribution platform.                                                                                   |
-| \gls{SWLC}       | Should be aware of the software life-cycle.                                                                                   | Should know where in the life-cycle their project is and which decisions are likely to lead to technical debt.                        | Should know how to manage and steer development/project resources accordingly. Should also have an understanding of the potential consequences of key project management decisions. |
-| \gls{SWREPOS}    | Should seamlessly interact with the repository of their project.                                                              | Should be well-versed in the intricacies of a repository, and probably interact with repositories of multiple projects.               | Should promote the use of repositories and be able to convey best practices to junior and senior RSEs.                                                                              |
+| \gls{SWREPOS}    | Should seamlessly interact with the repository of their project.                                                              | Should be well-versed in the intricacies of a repository, and probably interact with repositories of multiple projects.               | Should promote the use of repositories and be able to convey best practices of sharing and reviewing to junior and senior RSEs.                                                                              |
 | \gls{MOD}        | Should have a basic grasp of their piece of the software in order to use basic tools such as a debugger.                      | Should understand the characteristics of large parts of the codebase considering a variety of the metrics.                            | Should understand the big idea of the software project in order to define the task that the software solves.                                                                        |
 
 Table: Levels of software eng. skills expected per RSE career stage. {#tbl:comp-lvls-se}
@@ -1283,10 +1301,10 @@ and attend these additional modules to deepen their knowledge in the field.
 
 Core modules are of course drawn from the three pillars of the RSE and can be categorised accordingly.
 
-- \ac{SE} skills:
+- Software/Technical skills:
   - Foundational module: Here we have an introduction to programming: Emphasising use cases over programming paradigms, students learn at least two languages: a language that facilitates prototyping and data processing (e.g., \gls{Python} or \gls{R}) and a language for designing complex, performance-critical systems (e.g., \gls{C}/\gls{Cpp}). This exposes them to computers in a hands-on fashion and is the foundation for (\gls{DOCBB}, \gls{LIBS}).
   - Computing environment module: Programming languages are not enough to work in a landscape of many interconnected software components; hence we require something like software craftsmanship, where tools such as the Unix shell, version control systems, build systems, documentation generators, package distribution platforms, and software discovery systems are taught to strengthen skills in (\gls{LIBS}, \gls{DOCBB}, \gls{SWREPOS}, \gls{SRU}).
-  - Software architecture module: Here we teach software design and \ac{SE}, again strengthening (\gls{DOCBB}, \gls{LIBS}) on a more abstract level.
+  - Software engineering module: Here we develop foundational software engineering competencies (basic knowledge and skill regarding requirements engineering, software architecture and design, implementation, quality assurance, software evolution), again emphasising and strengthening (\gls{DOCBB}, \gls{LIBS}) on a more abstract level.
 
 - Research skills:
   - Optional domain mastery module: Additional minor research courses, but students with a home-domain already have the research part well-covered.