Resources for instructors of capstone courses in computing

Most computing programs now have some form of integrative or capstone course in which students undertake a significant project under supervision. There are many different models for such courses and conducting these courses is a complex task. This report is intended to assist instructors of capstone courses, particularly those new to the model of teaching and learning inherent in the capstone course.This paper discusses important issues that must be addressed when conducting capstone courses. These issues are addressed through a series of questions, with answers reflecting the way that different institutions have chosen to handle them, and commentary on the impact of these different choices. These questions include: Goals of the Course; Characteristics of Projects; Project Deliverables; Sponsors; Teams; Prerequisites and Preparation; Grading and Assessment; Administration and Supervision; and Reflection, Analysis and Review.Subsequently we present information about the companion Web site, intended as an active repository of best practice for instructors of capstone projects. The Web site will have examples of information about capstone courses and materials used by instructors. Readers are invited to contribute content to this site. The paper concludes with a bibliography of additional reference material and resources

Enhancing the social issues components in our computing curriculum: Computing for the social good

The acceptance and integration of social issues into computing curricula is still a work in progress twenty years after it was first incorporated into the ACM Computing Curricula. Through an international survey of computing instructors, this paper corroborates prior work showing that most institutions include the societal impact of ICT in their programs. However, topics often concentrate on computer history, codes of ethics and intellectual property, while neglecting broader issues of societal impact. This paper explores how these neglected topics can be better developed through a subtle change of focus to the significant role that ICT plays in addressing the needs of the community. Drawing on the survey and a set of implementation cases, the paper provides guidance by means of examples and resources to empower teaching teams to engage students in the application of ICT to bring about positive social outcomes – computing for the social good

Predicting Transitions in Low and High Levels of Risk Behavior from Early to Middle Adolescence: The TRAILS Study

The present study examined the joint development of substance use and externalizing problems in early and middle adolescence. First, it was tested whether the relevant groups found in previous studies i.e., those with an early onset, a late onset, and no onset or low levels of risk behavior could be identified, while using a developmental model of a single, underlying construct of risk behavior. Second, departing from Moffitt’s taxonomy of antisocial behavior, it was tested if early, but not late, onset risk behavior is predicted by a problematic risk profile in childhood. Data were used from TRAILS, a population based cohort study, starting at age 11 with two follow-ups at mean ages of 13.6 and 16.3 years. Latent transition analyses demonstrated that, both in early and middle adolescence, a single underlying construct of risk behavior, consisting of two classes (labeled as low and high risk behavior), adequately represented the data. Respondents could be clearly classified into four possible transition patterns from early to middle adolescence, with a transition from high to low being almost non-existent (2.5 %), low to low (39.4 %) and low to high (41.8 %) being the most prevalent, and high to high (16.2 %) substantial. As hypothesized, only the high-high group was characterized by a clear adverse predictor profile in late childhood, while the low-high group was not. This study demonstrates that the development of substance use is correlated with externalizing problems and underscores the theory that etiologies of early and later onset risk behavior are different

The Development of Criminal Style in Adolescence and Young Adulthood: Separating the Lemmings from the Loners

Despite broad consensus that most juvenile crimes are committed with peers, many questions regarding developmental and individual differences in criminal style (i.e., co-offending vs. solo offending) remain unanswered. Using prospective 3-year longitudinal data from 937 14- to 17-year-old serious male offenders, the present study investigates whether youths tend to offend alone, in groups, or a combination of the two; whether these patterns change with age; and whether youths who engage in a particular style share distinguishing characteristics. Trajectory analyses examining criminal styles over age revealed that, while most youth evinced both types of offending, two distinct groups emerged: an increasingly solo offender trajectory (83%); and a mixed style offender trajectory (17%). Alternate analyses revealed (5.5%) exclusively solo offenders (i.e., only committed solo offenses over 3 years). There were no significant differences between groups in individuals’ reported number of friends, quality of friendships, or extraversion. However, the increasingly solo and exclusively solo offenders reported more psychosocial maturity, lower rates of anxiety, fewer psychopathic traits, less gang involvement and less self reported offending than mixed style offenders. Findings suggest that increasingly and exclusively solo offenders are not loners, as they are sometimes portrayed, and that exclusively solo offending during adolescence, while rare and previously misunderstood, may not be a risk factor in and of itself

VDE: an emulation environment for supporting computer networking courses

Emulators have long been a valuable tool in teaching. Particularly in the OS course, emulators have allowed students to experiment meaningfully with different machine architectures. Furthermore, many such tools run in user-mode, allowing students to operate as system administrators without the concomitant security risks. Virtual Distributed Ethernet (VDE) is a system which emulates, in user-mode, all aspects of an internet, including switches, routers, communication lines, etc, in a completely realistic manner, consistent with the operation of such artifacts in the real world. VDE's can be implemented on a single computer, spread over several machines on the same LAN or scattered across the Internet. A VDE can interoperate with both real systems (via standard virtual interface/connectivity tools) and several virtual machine environments, support encryption, and actually run fast enough to support real applications. Furthermore, a VDE can interface/interoperate with real networks. VDN's have proven highly effective in supporting both undergraduate and graduate networking courses, and a wide range of student experiments and projects

Virtual Square in Computer Science Education

It is common to name as {em virtual} the imaginary space that can be created by software using computers and networks. This space is not only a set of processing and communications means and methods but it is also a space where humans can ``meet,'' exchange ideas, leave messages etc. Students in Computer Science must learn how to design, implement, manage and debug the systems and networks that create this virtual space. Furthermore, CS students need an experimental environment --a playground-- where they can develop their skills at creating and supporting these virtual environments. For this ``playground'' we propose a virtual world made up of emulated computer systems and emulated networks. This emulated world will be the students' testing environment, where they can run their own services, administer their own machines and set up security attacks without any danger to real networks and systems. It is a virtual space based on virtual machines and virtual networks but it is also a meeting place for computer science students, where they can test the effectiveness of their ideas. This ``space'' therefore is a {em twice} virtual space, which we call virtual to the second power or virtual squared ($V^{2}$). It is a also virtual place (a square) where different real computers, virtual systems and people can meet and communicate

A Poster about View-OS: a Process with a view

A process'es view of its execution environment is determined by the semantics of the available system calls; change the behavior of the system calls and one changes the process'es view of its environment. Operating systems typically implement the abstraction of a single view shared by all running processes. For example, all processes in a given system share the same view of the file system; the same pathname refers to the same file, mounting and unmounting remote or removable file systems have global effects. There are a few notable exceptions; system calls whose purpose is to solve problems related to having a solitary inflexible view of the environment. (e.g. chroot which is used for enforcing secure access to the file system.) View-OS is an approach for extending an existing OS via an abstract OS layer, which by applying a kind of polymorphism to process views, generalizes the chroot approach: the behavior of a system call can be defined on a process (group) by process (group) basis. Therefore, each process in View-OS has its own view of the execution environment, i.e. its own view on networking, file systems, existing devices, inter-process communication, etc. Furthermore, process view redefinition in View-OS can be selectively applied to only specific portions of a process'es ``default'' view: e.g. a process can change its view on the file system, or the networking service or even only on a subtree of the file system

Msocket: Multiple Stack Support for the Berkeley Socket API

The de-facto standard for network programming, the Berkeley socket API, supports several protocol families. Unfortunately, it has a significant limitation in only allowing a single implementation for each supported protocol family. Hence, using Berkeley sockets, it is impossible to access multiple distinct networking stacks for the same protocol, e.g. multiple TCP/IP stacks. This paper defines, msocket, an extension to the Berkeley socket API which overcomes this limitation. msocket has been implemented as a feature of the View-OS project. Finally, we illustrate the utility and effectiveness of our extended API by providing some examples of its use