The Agile methodologies have attracted the software development industry's attention due to their capability to overcome the limitations of the traditional software development approaches and to cope with increasing complexity in system development. Scrum is one of the Agile software development processes broadly adopted by industry. Scrum promotes frequent customer involvement and incremental short releases. Despite its popular use, Scrum’s requirements engineering stage is inadequately defined which can lead to increase development time and cost, along with low quality or failure for the end products. This research shows the importance of activity planning of requirements engineering in improving the product quality, cost, and scheduling as well as it points out some drawbacks of Agile practices and available solutions. To improve the Scrum requirements engineering by overcoming its challenges in cases, such as providing a comprehensive understanding of the customer’s needs and addressing the effects of the challenges in other cases, such as frequent changes of requirements, the Design Thinking model is integrated into the Scrum framework in the context of requirements engineering management. The use of the Design Thinking model, in the context of requirements engineering management, is validated through an in-depth scientific study of the IBM Design Thinking framework. In addition, this research presents an Items Prioritization dEcision Support System (IPESS) which is a tool to assist the Product Owners for requirements prioritization. IPESS is built on information collected in the Design Thinking model. The IPESS tool adopts Analytic Hierarchy Process (AHP) technique and PageRank algorithm to deal with the specified factors and to achieve the optimal order for requirements items based on the prioritization score. IPESS is a flexible and comprehensive tool that focuses on different important aspects including customer satisfaction and product quality. The IPESS tool is validated through an experiment that was conducted in a real-world project / Includes bibliography. / Dissertation (PhD)--Florida Atlantic University, 2021. / FAU Electronic Theses and Dissertations Collection

Call number: LD2668 .T4 1986 L36 / Master of Science / Computing and Information Sciences

Not available

No description available.

No description available.

No description available.

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

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.