Knowing when and how to seek academic help is crucial to the success of undergraduate computing students. While individual help-seeking resources have been studied, little is understood about the factors influencing students to use or avoid certain re- sources. Understanding students’ patterns of help-seeking can help identify factors contributing to utilization or avoidance of help resources by different groups, an important step toward improving the quality and accessibility of resources. We present a mixed-methods study investigating the help-seeking behavior of undergraduate computing students. We collected survey data (n = 138) about students’ frequency of using several resources followed by one-on-one student interviews (n = 15) to better understand why they use those resources. Several notable patterns were found. Women sought help in office hours more frequently than men did and computing majors sought help from their peers more often than non-computing majors. Additionally, interview data revealed a common progression in which students started from easily accessible but low utility resources (online sources and peers) before moving on to less easily accessible, high utility resources (like instructor office hours). Finally, while no differences between racial groups was observed, the lack of diversity in our sample limits these findings.

Verification is a process that checks whether a program G, implemented by a devel- oper, correctly complies with the corresponding requirement specifications. A verifier, whose interests may be different from the developer, will conduct such verification on G. However, as the developer and the verifier distrust each other probably, either of them may exhibit harmful behavior and take advantage of the verification. Generally, the developer hopes to protect the content privacy of the program, while the verifier wants to conduct effective verification to detect the possible errors. Therefore, a ques- tion inevitably arises: How to conduct an effective and efficient kind of verification, without breaking the security requirements of the two parties? We treat verification as a process akin to testing, i.e. verifying the design with test cases and checking the results. In order to make the verification more effective, we get rid of the limitations in traditional testing approaches, like black-box and white-box testing, and propose the “partial white-box verification”. Taking circuits as the description means, we regard the program as a circuit graph. Making the structure of the graph public, we manage to make the verification process in such a graph partially white-box. Via garbled circuits, commitment schemes and other techniques, the security requirements in such verification are guaranteed. / Thesis / Master of Science (MSc)

Expert software developer recommendation is a mature research field with many different techniques being developed to help automate the search for experts to help with development tasks and questions. But all previous research on recommending expert developers has had two constant restrictions. First, all previous expert recommendation work assumed that developers only demonstrate positive expertise. But developers can also make mistakes and demonstrate negative expertise, referred to as inexpertise, and show which concepts they don't know as well. Previous research on developer expertise hasn't taken inexpertise into account. Another restriction is that all previous expert developer recommendation research has focused on recommending developers for a single development task or expertise need, such as fixing a bug report or helping with a change request. But not all expertise needs can be easily classified into one of these groups, and having different techniques for every possible task type would be difficult and confusing to maintain and use. We find that inexpertise exists, can be measured, and that it can be used to direct inspection effort to find potentially incorrect or buggy commits. Additionally we investigate how different expertise finding techniques perform on a diverse set of long and short expertise queries and develop new techniques that can get more consistent cross query performance. / Master of Science

Virtual Reality is a young field and needs more research to mature. In order to help speed the maturity process research was performed to see if knowledge from the domain of software engineering could be applied to the development of Virtual Reality software. Software engineering is a field within computer science that studies how to improve both product and process. One of the sub-fields of software engineering is metrics, which seeks to measure software products and processes. This allows for prediction of certain attributes such as quality. There are several software toolkits that exist in virtual reality that have not had formal software engineering methodologies applied during their development. This research looks at applying knowledge gained from the metrics discipline to the software toolkits used in virtual reality. When metrics are used to measure the toolkits in virtual reality, the metrics seem to behave--produce similar significant correlations--in a similar fashion as when they are applied in previously studied domains. / Master of Science

by Lai Kin Wing. / Thesis (M.B.A.)--Chinese University of Hong Kong, 1990. / Bibliography: leaves 46-47. / Abstract --- p.iii / Table of Contents --- p.iv / List of Exhibits --- p.vi / Chapter / Chapter 1. --- Introduction --- p.1 / Chapter 2. --- Methodology --- p.4 / Chapter 3. --- Computer Aided Software Engineering (CASE) --- p.6 / Chapter 3.1 --- Problems of applications development --- p.6 / Chapter 3.2 --- The promise of CASE technology --- p.8 / Chapter 3.3 --- Components of CASE --- p.11 / Chapter 3.3.1 --- Front-end Analysis and Design --- p.11 / Chapter 3.3.2 --- Back-end Code Generation --- p.14 / Chapter 3.3.3 --- Project Support --- p.15 / Chapter 3.3.4 --- Repository --- p.16 / Chapter 3.3.5 --- Re-engineering --- p.17 / Chapter 4. --- Current offerings in the market --- p.21 / Chapter 5. --- Considerations of implementing CASE products --- p.26 / Chapter 6. --- Acceptance of CASE tools in Hong Kong --- p.30 / Chapter 6.1 --- Questionnaire survey results --- p.30 / Chapter 6.2 --- A caution about the survey questionnaire --- p.41 / Chapter 6.3 --- Some conclusions of the survey --- p.42 / Chapter 7. --- Conclusions and recommendations --- p.44 / Bibliography --- p.46 / Chapter Appendix I : --- Survey questionnaire / Chapter Appendix II : --- List of CASE software products / Chapter Appendix III : --- Product brochure of Information Engineering Workbench / Chapter Appendix IV : --- Product brochure of Bachman / Chapter Appendix V : --- Product brochure of Excelerator / Chapter Appendix VI : --- Companies to which questionnaires were sent / Chapter Appendix VII : --- List of mainframe and mid-range computers / Chapter Appendix VIII : --- Calculation of ratings of CASE success factors

The purpose of Moops is to bridge the gap between PSP Scriber, geared very specifically to the CSCI655 class, and other available PSP implications which are so general they are difficult to use immediately without valuable time spent learning the software. Moops is a PHP/MySQL based web application designed to provide the students taking the CSCI655 graduate software engineering course at CSUSB with an intuitive, easy to use tool to implement the Personal Software Process (PSP). Moops eliminates the possibility of errors in calculations by completing all calculations for the user.

An assessment of a software engineering program has been carried out by reviewing state-of-the-art literature pertaining to software engineering education. Six surveys have been adopted and the result implies that the balance of the curriculum should be revised, and that software engineering education ought to expand the technical oriented knowledge areas somewhat. Relevant curriculum data have been derived hereby, which also confirms other studies in the area. This data, along with a benchmark of the software engineering program to the Software Engineering Body of Knowledge (SWEBOK), is very constructive to universities as it assists educators, trainers, and software engineering practitioners in evaluating, designing, and recommending existing and proposed curricula. / This is the final revision of the thesis. Author may be contacted on +464458038. See also paper at the 18th Conference on Software Engineering Education and Training (CSEE&T), Ottawa, Canada.

The gap between software engineering education and the software engineering industry is a prevalent factor for both the students and the companies recruiting them. The gap is specified as the lack of knowledge software engineering students obtain relative to what the industry requires. This gap increases the difficulty for the students whenmoving from education to industry. This thesis aims to provide insight for what role the capstone project played for the graduate students’ transition to industry by looking at it from a CDIO perspective. The subjects for this research were graduate students who now work in the software engineering industry and who realised their studies up to three years earlier. A total of 38 people took part in this research by answering a questionnaire. They provided their opinions on how they experienced their capstone project and how they now experience their work assignments. This research used metadata to categorically separate the respondents into groups to find outliers. The results show that 94% of the respondents got to perform three or more CDIO criteria in their capstone projects. The respondents also recognize that they are able to perform their industry assignments in terms of the CDIO criteria.

Thesis (MBA)--Stellenbosch University, 2015. / ENGLISH ABSTRACT: Software development is a relatively young science and involves certain tools, techniques, documentation aids and processes that are applied to deliver a software project. As hardware, software and business needs advanced, so did the processes used in managing software development. It is a dynamic and complex process and each development environment or project has its own unique characteristics. For this reason the methodologies followed during the development process is very often debated. Software development teams have a wide array of methodologies to choose from. The development team usually decides what the key success factors are to deliver a software product, and then examines each one within the framework of a list of potential methodologies. This way the team can compare which methodology would best suit their needs. Factors used to evaluate which methodology to follow, includes the size of the project team, rate of expected changes, the primary goal of the project, how requirements will be managed, communication structures that will be followed, the nature of the relationship with the customer, and the organisational culture in the customer organisation. This research report takes a comparative look at Waterfall methods versus Agile methods.

Le but de cette étude est de présenter rapidement (en français) le langage Cobol, de le comparer aux langages commerciaux qui l'ont précédé et d'en faire la critique en tant que langage commercial, de le comparer à Algol et de le critiquer en tant que langage peu formel, de présenter les grandes lignes d'un compilateur sur un machine binaire à mots avec toutes les difficultés que cela représente, et de conclure sur l'avenir de Cobol