M.Sc. (Computer Science) / This study addresses the topic of integration between CASE tools and software engineering methodologies. Specific attention is given to the object-oriented paradigm to solve the problem of integration. The component developed in this study to handle the integration is the so-called feedback loop mechanism. The feedback loop is the focus of the study. A number of CASE tools are available today. These tools help developers achieve specific aims and to solve specific problems. Similarly, a number of different software development methodologies abound. Due to the fact that these methodologies are usually not specific to the use of CASE tools, these methodologies can be used for a variety of development environments. The problem addressed by this study is the direct integration of CASE tools and software engineering methodologies. A number of studies have been carried out with regard to both CASE tools and software engineering methodologies. A discussion of current trends in both the CASE tool and methodology arenas is presented at the beginning of this study. Also, the problems experienced with more traditional approaches are discussed. Given that the feedback loop mechanism is developed during the course of this study, a detailed discussion is presented regarding the components to be used in the construction of the feedback loop. The object-oriented paradigm is presented as the best solution to the integration problem. In fact, the object-oriented paradigm forms the core of the feedback loop. By making use of the object-oriented approach, the processes involved in the integration of the CASE tool and the methodology may be mapped accurately. Repository structures such as relational tables and stored procedures, or triggers, are also used in the construction of the feedback loop...

Empirical methodologies have recently attracted increasing attention from the broader software engineering community. In particular, organisational issues and the human role in software development have been addressed. Qualitative research approaches have been identified as necessary for understanding human nature. One qualitative methodology which has become increasingly recognised in the software engineering community is ethnography. It is also the qualitative approach that is addressed in this thesis, i.e. ethnography in relation to software engineering. Ethnography emphasises the members point of view in an effort to understand the organisation of a social, cultural and technical setting. Until now, only a handful of ethnographic studies focusing on software engineering have been carried out in accordance with the original conception of ethnography; these studies have traditionally been performed by sociologists. The understanding and application of ethnography by software engineers differ from that of sociologists as it gives up the studied people's point of view in the analysis of data. The thesis is based on two independent ethnographic studies where the ‘inside’ perspective which complies with the original understanding of the methodology is applied. Using these examples as a basis, the relation between ethnography and software engineering research is explored. The objective of this thesis is to promote ‘ethnographic knowledge’ by giving an overview of ethnographic work within software engineering, presenting an original understanding of ethnography, comparing software engineers' understanding of ethnography with the original understanding of ethnography, demonstrating how the different implicit research attitudes of ethnographers and software engineers produce different research discourses, and finally pointing to an opportunity to combine ethnography, which contributes an ‘inside perspective’, with software engineering's need for constant improvement.

Defect prediction aims at identifying software artifacts that are likely to exhibit a defect. The main purpose of defect prediction is to reduce the cost of testing and code review, by letting developers focus on specific artifacts. Several researchers have worked on improving the accuracy of defect estimation models using techniques such as tuning, re-balancing, or feature selection. Ultimately, the reliability of a prediction model depends on the quality of the dataset. Therefore effort has been spent in identifying sources of noise in the datasets, and how to deal with them, including defect misclassification and defect origin. A key component of defect prediction approaches is the attribution of a defect to a projects release. Although developers might be able to attribute a defect to a specific release, in most cases a defect is attributed to the release after which the defect has been discovered. However, in many circumstances, it can happen that a defect is only discovered several releases after its introduction. This might introduce a bias in the dataset, i.e., treating the intermediate releases as defect-free and the latter as defect-prone. We call this phenomenon a “sleeping defect”. We call “snoring” the phenomenon in which classes are affected by sleeping defects only, that would be treated as defect-free until the defect is discovered. In this work, we analyze, on data from more than 4,000 bugs and 600 releases of 20 open source projects from the Apache ecosystem for investigating: 1)the magnitude of the sleeping defects, 2) the magnitude of the snoring classes, 3)if snoring impacts the evaluation of classifiers, 4)if snoring impacts classifier accuracy, and 5)if removing the last releases of data is beneficial in reducing the negative impact of the snoring noise on classifiers accuracy. Our results show that, on average across projects: 1)most of the defects in a project slept for more than 19% of the existing releases, 2)the missing rate is more than 50% unless we remove more than 20% of the releases, 3) the relative error in measuring the classifier accuracy achieved by using a dataset with snoring is about 100% in all accuracy metrics other than AUC, 4) the presence of snoring decreases the accuracy in each of the 15 classifiers, in each of the 6 accuracy metrics. For instance, Recall, F1, Kappa and Matthews decreases by about 80%, and 5) removing one release of data is better than removing no data in all accuracy metrics. For instance, Recall, F1, Kappa and Matthews increase by about 30%.

<p>Paramount Salt Handicraft A wholesale Himalayan salt company was previously doing business in traditional way and was limited only to the local market. However from the start day management was planning to expand the business to more locations and to attract more customers. So to expand the business and to attract the international customers and customers from other cities of Sweden it was necessary to make it available over the internet so that customers can easily get knowledge about the company’s products and purchase them. So the need of an online web shop was realized to bring the company’s plan into reality. The online shop will be act as a medium of interaction between the customers and the company and it will enable the customers to buy products online and make payments electronically and after that the products will delivered to them. Throughout the process the customers can easily track the overall status of their orders.</p>

No description available.

No description available.

No description available.

No description available.

No description available.

No description available.