No description available.

No description available.

Creating documentation is a challenging task in software engineering and most techniques involve the laborious and sometimes tedious job of writing text. This thesis explores an alternative to traditional text-based documentation, the screencast, which captures a developer’s screen while they narrate how a program or software tool works. This thesis presents a study investigating how developers produce and share developer-focused screencasts using the YouTube social platform. First, a set of development screencasts were identified and analyzed to determine how developers have adapted to the medium to meet the demands of development-related documen- tation needs. These videos raised questions regarding the techniques and strategies used for sharing software knowledge. Second, screencast producers were interviewed to understand their motivations for creating screencasts, and to uncover the perceived benefits and challenges in producing code-focused videos. From this study a theory was developed describing the techniques used by devel- opers in screencasts. This thesis also discusses YouTube’s role in the social developer ecosystem, and presents a list of best practices for future screencast creators. This work lays the groundwork for future studies exploring how screencasts can play a role in sharing software development knowledge. / Graduate / 0984 / lmacleod@uvic.ca

Software development projects typically involve repeated interactions among several groups of people. This setting seems well suited for an analysis by means of the standard-model of the evolution of cooperation, the Iterated Prisoner's Dilemma. Computer simulations of a population of stochastic reactive strategies show that the existence of intergroup discrimination can be modeled endogeneously as a result of noise due to misperception of the opponent's move. (author's abstract) / Series: Working Papers on Information Systems, Information Business and Operations

No description available.

The software development life-cycle is comprised of a series of successive activities consisting of analysis, design, implementation, system testing and maintenance. During the analysis phase we do planning and requirements definition for the software product. The design phase, which follows the analysis phase, is concerned with deciding exactly how the software will be implemented. However, the actual transition from the analysis to the design phase is not well documented. There exists an information gap between these two phases.In this study, the transition from the analysis to the design phase is explored by using the reverse engineering method which essentially proceeds from the design phase back to the analysis phase. This study is based on the design of an approximately five thousand line project - an Executive Calendar, which is first designed using a computer-aided software engineering (CASE) tool called DesignAid. The transition is documented in order to exploit the isomorphisms between each phase.The end results show that by documenting the mapping between the analysis phase and the design phase, the process of transition from one phase to another could be partly automated. By using the reverse engineering method, the elements which are necessary in the transition between the analysis and the design phase can be easily identified. Being able to identify these elements, one can reduce the amount of effort required to transform user requirements to design, and thus improve software productivity. / Department of Computer Science

A major reengineering goal is software reuse. Effective reuse of knowledge, processes and products from previous software developments can reduce costs and increase both productivity and quality in software projects.This thesis extensively tests five projects produced by the graduate software engineering class at Ball State University. Each project has the same set of requirements.Each project is also analyzed based on subjective criteria, for example documentation, use of mnemonics for variable names and ease of understanding. Based on the outcome of testing and subjective analysis, reusable parts are identified.Metrics are collected on all of these projects. This thesis compares the metrics collected on the modules identified for reuse, and the same metrics collected on the non-reusable modules, to determine if there is a statistically significant difference in those metrics between the two groups. Metrics which are good predictors of reusable modules are identified.Metrics which are found to be good predictors of reusable modules include: number of in-parameters, number of data structure manipulations and central calls. / Department of Computer Science

Several have reported observations that sometimes ignorance of the domain in a software development project is useful for promoting the elicitation of tacit assumptions and out- of-the-box ideas. This thesis reports work putting the observation to two empirical tests. First, a survey was conducted among software development managers of varying experience to determine what software development activities they thought were at least helped by domain ignorance. Second, transcripts from fourteen interviews of presumably-domain- ignorant immigrants to new software development projects at one large company were examined to determine if the activities performed by those with the smoothest immigrations were activities that are at least helped by domain ignorance. The conclusions are that ignorance plays an important role in software development but there are a lot of other factors that influence immigration smoothness.

M.Sc. / The following questions led to this study: Why are there still so many approaches to the software generation process without one single approach taking the lead? Not only are there several methodologies available for the software generation process, but a methodology is not in use for long before it is replaced by an improved version or even another methodology. This is as a result of continuing further development and research. Sometimes the new methodology is not necessarily an improvement, but a paradigm shift. An example of this is object-orientation which followed shortly after the introduction of CASE as an alternative to software generation. Why are users to a large extent still dissatisfied and disillusioned with the software generation process even though they are more involved with it than before? User are more involved in the software generation process as a result of the availability of sophisticated tools, as well as joint sessions with the developer during the analysis and design stages of the software generation process. Yet, despite this, software systems in most cases still do not perform according to users' expectations. Why did the use of formal methodologies, based on successful techniques of the engineering field, only result in a limited improvement of the quality, control and operationalization of the software system? The cost of maintenance is still very high in relation to the total cost of generating a software system. The same degree of success attained in, say, the engineering field, could not be achieved [AND I]. Why is there a simultaneous movement towards incremental approaches and formal methods although these approaches are really moving in opposite directions? The incremental approach is based on obtaining quick results through prototyping without necessarily following a formal methodology [AND2]. Formal methods, on the other hand, attempt to formalize the software generation process through mathematical transformations. The advantage of using these mathematical transformations is that automation and verification of processes can be achieved [McC1]. Both these approaches show promising results, but the incremental approach might suit the developer better and is already used widely by practitioners. Why is it so difficult to find the correct methodology for generating a software system? The selection of an appropriate methodology is extremely difficult because of the variety of methodologies, technologies and hardware available. Some methodologies are also used for only a limited period because of rapid advances in technology. Why do sophisticated and user-friendly tools not succeed in simplifying the software generation process? Despite sophisticated tools such as CASE, where the user of these tools is guided through the different steps of the methodology, these tools have not succeeded in delivering the results expected by industry. The problems experienced during the software generation process are investigated. In order to distinguish between different approaches to software generation, is it necessary to place different approaches in relation to one another by considering the different elements of each. The characteristics and constraints of the software generation process must also be considered. All the issues pertaining to the software generation process will be discussed in terms of the problem statement.

Bibliography: pages 102-107. / A Design Workbench has been built for Napier88 [MBC+94] as part of the natural progression towards developing better product systems and improving software construction tools. The system includes a Metamodeller (enabling users to specify the data and process models they prefer), a Model Builder which supports multiple coexisting models and a Target System Generator. Experience using the Workbench has shown that it is easy to use, increases productivity, improves programming standards and facilitates code sharing. This thesis demonstrates the benefits of orthogonal persistence for Computer-Aided Software Engineering by describing an initial design environment and its subsequent extension to include support for multiple co-existing models.