Software forms around a requirement. Defining this requirement is often regarded as the hardest part of software engineering. The requirement however has an additional complexity as, once defined, it will change with time. This change of requirement can come either from the user, or from the rapid advances in 'computer' technology. How then can software succeed to continue to remain 'current' both in terms of requirements and technology in this forever changing environment? This thesis examines the issues surrounding 'change' as applied to software and software engineering. Changing requirements are often deemed a 'curse' placed upon software engineers. It has been suggested, however, that the problems associated with change exist only in the attitude of software engineers. This is perhaps understandable considering the training methods and tools available to supposedly 'help' them. The evidence shows that quality of management and experience of personnel involved in development contribute more significantly to the success of a development project than any technical aspect. This unfortunately means that the process is highly susceptible to staff turnover which, if uncontrolled, can lead to pending disaster for the users. This suggests a 'better' system would be developed if 'experience' was maintained at a process level, rather that at an individual level. Conventional methods of software engineering are based upon a defined set of requirements which are determined at the beginning of the software process. This thesis presents an alternative paradigm which requires only a minimal set of requirements at the outset and actively encourages changes and additional requirements, even with a mature software product. The basis of this alternative approach is the fonn of the 'requirements specification' and the capturing and re-use of the 'experience' maintained by the software process itself.

The following research used data from the SSE to determine whether socialization or discrimination can explain the lower status of female engineers, compared to men. It was learned that female engineers with children are as committed to their careers as childless female engineers. Moreover, there is no difference in income or job status between these two groups. There is also no significant difference in income between male and female engineers when controlling for employment status, degree, job status and experience. However, female engineers are not found in management positions as often as their male colleagues, even after controlling for experience. This lower job status, in turn, affects the women's incomes. A reason for the lower status of female engineers is likely due to engineering being very male-dominated. No such difference in job status exists in the field of computer science, where the proportion of women is much higher.

[Abstract]: The traditional approach to training novice programmers has been to provide explicit programming knowledge instruction but to rely on implicit instruction of programming strategies. Studies, reported in literature, have discovered universally poor results on standardised tests for novices studying under this traditional approach.This dissertation describes the explicit integration of programming strategies into instruction and assessment of novice programmers, and the impact of this change ontheir learning outcomes.An initial experiment was used to measure the performance of students studying under a traditional curriculum with implicitly taught programming strategies. Thisexperiment uncovered common flaws in the strategy skills of novices and revealed weaknesses in the curriculum. Incorporation of explicit strategy instruction wasproposed.To validate a model of strategies as being authentic and appropriate for novice instruction, an experiment with experts was conducted. Experts were asked to solvethree problems that a novice would typically be expected to solve at the end of an introductory programming course. Experts‟ solutions were analysed using Goal/PlanAnalysis and it was discovered that experts consistently applied plans, the subalgorithmic strategies suggested by Soloway (1986). It was proposed that plans could be adapted for explicit inclusion in an introductory programming curriculum.Initially a curriculum incorporating explicit strategy instruction was tested in an artificial setting with a small number of volunteers, divided into control andexperimental groups. The control group was taught using a simplified traditional curriculum and the experimental group were exposed to a curriculum which explicitly included programming strategies. Testing revealed that experimental group participants applied plans more than control group participants, who had been expected to learn these strategies implicitly. In interviews, experimental participants used strategy-related terminology and were more confident in the solutions they had created. These results justified a trial of the curriculum in an actual introductory programming course.When explicit instruction of programming strategies was incorporated into an actual introductory programming curriculum, novices achieved superior results whencompared to results from the initial experiment. Novices used strategies significantly more when these strategies were incorporated explicitly into instructional materialsand assessment items.This series of experiments focussed on explicitly teaching specific programming strategies rather than teaching problem-solving more generally. These experimentalresults demonstrate that explicit incorporation of programming strategies may improve outcomes for novices and potentially improve the potential of expertprogrammers in future.

Thesis (M.App.Sc.) - Carleton University, 2002. / Includes bibliographical references (p. 69-70). Also available in electronic format on the Internet.

Thesis (Ph. D.)--Virginia Polytechnic Institute and State University, 1994. / Vita. Abstract. Includes bibliographical references (leaves 105-108). Also available via the Internet.

Este estudo procura identificar, medir e avaliar as práticas dos empregadores do Brasil e do Canadá em relação à gestão do capital intelectual de seus desenvolvedores de software, comumente chamados de programadores. O trabalho condensa, através da revisão e análise dos principais autores do assunto, os pressupostos básicos da boa gestão do capital intelectual. Tais pressupostos foram determinados especificamente para os desenvolvedores de software, que são agentes nucleares na indústria da tecnologia da informação, tecnologia essa que é onipresente em todas as instituições modernas. A partir desses pressupostos básicos, foram definidos 13 Índices de Capital Intelectual, que possibilitaram a criação de um questionário eletrônico disponibilizado na internet, no qual profissionais do Brasil e do Canadá responderam após serem convidados através do disparo em massa de mensagens de e-mail, gerando assim os dados primários. Os 13 Índices de Capital Intelectual propostos são: Índice de Instrução, Índice de Treinamento, Índice do Sistema de Conhecimento Organizacional, Índice Ocupacional, Índice de Satisfação, Índice Motivacional, Índice Vocacional, Índice de Coleguismo, Índice do Poder de Decisão (empowerment), Índice de Contato Direto com Clientes, Índice de Rotatividade, Índice Hierárquico e Índice do Papel Contábil. Através de uma metodologia original proposta pelo autor, os resultados da pesquisa de campo, fartamente ilustrados com gráficos, mostraram que os respondentes do Canadá obtiveram melhor resultado em 7 índices, enquanto que os brasileiros superaram os canadenses nos demais 6 índices. / This study aims to identify, measure, and evaluate the practices of employers in Brazil and Canada in relation to the management of intellectual capital of its software developers, commonly called programmers. The study condenses, through the review and analysis of the principal authors of the subject, the basic assumptions of the good management of intellectual capital. These assumptions were determined specifically for software developers, who are nuclear agents in the information technology industry, the technology that is omnipresent in all modern institutions. From these basic assumptions, were defined 13 Intellectual Capital Indexes, which enabled the creation of an electronic questionnaire available on the Internet, in which professionals from Brazil and Canada responded after being invited through a mass e-mail sending, generating the primary data. The 13 Intellectual Capital Indexes proposed are: Education Index, Training Index, Organizational Knowledge System Index, Occupational Index, Satisfaction Index, Motivational Index, Vocational Index, Comradeship Index, Empowerment Index, Index of Direct Contact with Customers, Turnover Index, Hierarchical Index, and Accounting Role Index. Using an original methodology proposed by the author, the results of field research, fully illustrated with charts, showed that respondents in Canada obtained better results in 7 indexes, while the Brazilians beat the Canadians in the other 6 indexes.

No description available.

The objective of this study was to determine whether computer programmers would organize reserved words by programming language or by conceptual category, when given an opportunity to use either strategy. Twenty-seven participants, stratified by programming experience level (novice, intermediate, and expert), were given sixteen reserved words on index cards. The words were taken from four programming languages, as well as six conceptual categories. Participants were given both a recognition and a recall task. Organizing the words by conceptual category enabled the expert programmers to perform significantly better on the recall task than experts who organized by language. In addition, they made fewer recognition errors, and had more structured recall, in terms of recalling the words by the categories in which they were studied. Expert computer programmers, similar to natural language multilinguals, can recall more (reserved) words when they are organized by conceptual categories rather than by (programming) language. It is hypothesized that this is because human memory is organized in a fundamentally interdependent (across languages) manner in many domains other than natural language, such as computer programming. / Master of Arts

As Scratch has become one of the most popular educational programming languages, understanding its common programming idioms can benefit both computing educators and learners. This understanding can fine-tune the curricular development to help learners master the fundamentals of writing idiomatic code in their programming pursuits. Unfortunately, the research community's understanding of what constitutes idiomatic Scratch code has been limited. To help bridge this knowledge gap, we systematically identified idioms as based on canonical source code, presented in widely available educational materials. We implemented a tool that automatically detects these idioms to assess their prevalence within a large dataset of over 70K Scratch projects in different demographic and project categories. Since communal learning and the practice of remixing are one of the cornerstones of the Scratch programming community, we studied the relationship between common programming idioms and remixes. Having analyzed the original projects and their remixes, we observed that different idioms may associate with dissimilar types of code changes. Code changes in remixes are desirable, as they require a meaningful programming effort that spurs the learning process. The ability to substantially change a project in its remixes hinges on the project's code being easy to understand and modify. Our findings suggest that the presence of certain common idioms can indeed positively impact the degree of code changes in remixes. Our findings can help form a foundation of what comprises common Scratch programming idioms, thus benefiting both introductory computing education and Scratch programming tools. / Master of Science / With over 68 million users and growing, Scratch has become one of the most popular programming languages for introductory computing learners. As with learning any programming language, understanding common programming idioms used in the language's application domain is important for both computing educators and learners. Educators need this understanding in order to fine-tune their curricular development, while learners can leverage this knowledge to effectively master the fundamentals by writing idiomatic code. Unfortunately, our understanding of what constitutes idiomatic Scratch code thus far has been limited. To address this knowledge gap, we systematically identified idioms based on source code with good code quality, as presented in widely available educational materials. We implemented a tool that automatically detects these idioms to assess their prevalence within a large, diverse dataset of over 70K Scratch projects. Since communal learning and the practice of remixing are one of the cornerstones of the Scratch programming community, we studied the relationship between common programming idioms and remixes. Having analyzed the original projects and their remixes, we found that different idioms may associate with dissimilar types of code changes. The ability to change a project in its remixes hinges on the project's code being easy to understand and modify. Our findings suggest that the presence of certain common idioms can positively impact the degree of code changes in remixes. Our findings can help form a foundation of what comprises common Scratch programming idioms, thus benefiting both introductory computing education and Scratch programming tools.

Static analysis tools can be used to help programmers identify problems in their code. However, these tools often assume that developers have some programming background knowledge, so they can be hard to use in an educational context. We investigated the most common FindBugs errors from student code submissions and determined those errors that were related to incorrect solutions to problems and potential struggling for students. FindBugs is a static analysis tool that looks for incorrect patterns in Java bytecode analysis to identify potential coding flaws. For the common errors, we rewrote some of the original FindBugs messages to help students more easily understand the problems with their code. We found that students with at least one FindBugs warning in their final submission to an assignment had more submissions, longer work times, and lower correctness scores than students who did not have a FindBugs warning in their final submission. Adding modified FindBugs feedback to the automated grader resulted in students making fewer submissions and decreasing the length of time required to complete assignments. / Master of Science / Professional software developers use automated tools when they code to help them catch potential coding problems. These tools are difficult for novice student programmers because they do not have the same level of background as professionals. In this work, we attempted to change the feedback given by these tools so that students could understand it and use it to fix their code. We found that, across all of the undergraduate courses in this study, FindBugs warnings were associated with students having more trouble with assignments. When students could see FindBugs warnings, their time to complete assignments and the number of attempts they made both went down.