We needed to design a module covering both discrete maths and algorithms for a Work Based Learning (WBL) Software Engineering degree programme, where students spend half their time at their employers' workplace. This entails deciding the order of topics, and explaining that to students. Sequence in the course is only one kind of relationship between topics in the module; relevance to work is another. Such explaining is a neglected educational issue. This paper addresses how to convey these relationships to learners. Because of the WBL context, it is inevitable that questions about how pieces of academic learning relate to the work context (which these students are already experiencing) arise immediately and vividly for them. This is important because it affects learner motivation, sometimes greatly, and also whether they are likely to learn in a surface or a deep mode. A given learner's grasp of these relationships is both individual and changes over time. Because of this, the general pedagogical approach discussed here is “little and often”: raising it a number of times, with an emphasis not on one exhaustive and rigid view but on how different students often see it differently, and encouraging each to gradually develop their own view. The concept map diagram in this paper illustrates only one example of how the web of connections might be represented and conveyed during the course.

As more companies and governments build and use machine learning models to automate decisions, there is an ever-growing need to monitor and evaluate these models' behavior once they are deployed. Our team at CognitiveScale has developed a toolkit called Cortex Certifai to answer this need. Cortex Certifai is a framework that assesses aspects of robustness, fairness, and interpretability of any classification or regression model trained on tabular data, without requiring access to its internal workings. Additionally, Cortex Certifai allows users to compare models along these different axes and only requires 1) query access to the model and 2) an “evaluation” dataset. At its foundation, Cortex Certifai generates counterfactual explanations, which are synthetic data points close to input data points but differing in terms of model prediction. The tool then harnesses characteristics of these counterfactual explanations to analyze different aspects of the supplied model and delivers evaluations relevant to a variety of different stakeholders (e.g., model developers, risk analysts, compliance officers). Cortex Certifai can be configured and executed using a command-line interface (CLI), within jupyter notebooks, or on the cloud, and the results are recorded in JSON files and can be visualized in an interactive console. Using these reports, stakeholders can understand, monitor, and build trust in their AI systems. In this paper, we provide a brief overview of a demonstration of Cortex Certifai's capabilities.

Academics and employers can partner to deliver professional software engineering education via work-based learning (WBL) programmes. These programmes have the potential to engage and motivate under-represented groups, including those that would not normally engage in higher education. However, challenges still exist in supporting such individuals in participating in WBL programmes. Consequently, we discuss a project on broadening participation in WBL software engineering to support individuals from under-represented groups to participate in software engineering education.

Cooperative programmes are principally partnerships between academia and industry to deliver education partly on campus and partly in the workplace. Mentors in the workplace are crucial in such cooperative programmes as they scaffold appropriate development activities for students. A workplace mentor in this situation is important not only for the development of detailed technical knowledge, but also in the development of software engineering skills that are almost never in fact taught in higher education, e.g. navigating large, neglected code bases. Consequently, workplace mentors are a key component of any high-quality education programme delivered in partnership with industry. However, higher education institutions and enterprises not only need to appreciate the importance of mentors in such schemes, but also ensure such staff are supported to use their experience to increase their skill as a mentor. Mentors need the space and support to reflect on their own practice, develop skills and attain new knowledge. In this sense, the challenge is not dissimilar to that faced by computing science school teachers that need to continually consider their own practice as well as have the time to consider emerging programming languages and frameworks. Many of the structures and existing research on how to support computing science school teachers could be adapted to support these workplace mentors, e.g. support groups.

Goal-directed problem-solving labs can lead a student to believe that the most important achievement in a first programming course is to get programs working. This is counter to research indicating that code comprehension is an important developmental step for novice programmers. We observed this in our own CS-0 introductory programming course, and furthermore, that students weren't making the connection between code comprehension in labs and a final examination that required solutions to pencil-and-paper comprehension and writing exercises, where sound understanding of programming concepts is essential. Realising these deficiencies late in our course, we put on three 3-hour optional revision evenings just days before the exam. Based on a mastery learning philosophy, students were expected to work through a bank of around 200 pencil-and-paper exercises. By comparison with a machine-based hackathon, we called this a Thinkathon. Students completed a pre and post questionnaire about their experience of the Thinkathon. While we find that Thinkathon attendance positively influences final grades, we believe our reflection on the overall experience is of greater value. We report that: respected methods for developing code comprehension may not be enough on their own; novices must exercise their developing skills away from machines; and there are social learning outcomes in programming courses, currently implicit, that we should make explicit.

Introductory programming classes are renowned for their high dropout rates. The authors propose that this is because students learn to adopt a fixed mindset towards programming. This paper reports on a study carried out with an introductory programming class, based on Dweck's mindset research. Combinations of three interventions were carried out: tutors taught mindset to students; growth mindset feedback messages were given to students on their work; and, when stuck, students were encouraged to use a crib sheet with pathways to solve problems. The study found that the mixture of teaching mindset and giving mindset messages on returned work resulted in a significant change in mindset and a corresponding significant change in test scores - improvements in test scores were found in a class test given immediately after the six-week intervention and at the end-of-year exam. The authors discuss the results and the strengths and weaknesses of the study.

Abstract This paper describes the evolution of the design and implementation of a distributed run‐time system that itself is designed to support the evolution of the topology and implementation of an executing, distributed system. The three different versions of the run‐time architecture that have been designed and implemented are presented, together with how each architecture addresses the problems of topological and functional evolution. In addition, the reasons for the rapid evolution of the design and implementation of the architecture are also described. From the lessons learned in both evolving the design of the architecture and in trying to provide a run‐time system that can support run‐time evolution, this paper discusses two generally applicable observations: evolution happens all the time, and it is not possible to anticipate how systems will evolve as designs; and large, run‐time systems do not follow a predictable path. In addition to this, rapid prototyping has proved to be extremely useful in the production of the three architectures; this kind of prototyping has been made much easier by designing the core set of Java abstractions in terms of interfaces; and building an architecture that allows as many decisions as possible to be made at run‐time which has produced a support system that is more responsive to the user as well as the distributed environment in which it is executing. Copyright © 2003 John Wiley & Sons, Ltd.

The discipline of software engineering can be extended in a natural way to deal with the issues raised by a systematic approach to the design of human-machine interfaces. Two main points are made: that the user should be treated as part of the system being designed, and that projects should be organized to take account of the current (small) state of a priori knowledge about how to design interfaces.

This paper reports on a study investigating the strengths and weaknesses of questionnaires as software evaluation tools. Two major influences on the usefulness of questionnaire-based evaluation responses are examined: the administration of the questionnaire, and the background and experience of the respondent. Two questionnaires were administered to a large number of students in an introductory programming class. The questionnaires were also given to a group of more experienced users (including course proctors). Respondents were asked to evaluate the text editor used in the class along a number of dimensions; evaluation responses were solicited using a number of different question types. Another group of students received the questionnaire individually, with part of it presented on the computer; a third group also evaluated an enhanced version of the editor in followup sessions.