An Application Of The Rational Unified Process For Requirements Analysis

The Rational Unified Process® (RUP)[1] is an effective implementation technique for object oriented systems development.  The RUP® approach allows for flexible process modification and a customization of artifacts to meet the needs of the particular situation.  Marriott International developed a variation of this process as its standard for its SDLC.  This process was implemented in the requirements analysis and design phases of a software project for the Ritz-Carlton subsidiary.  A context-level treatment of the RUP® metamodel produced use cases and a supplementary specification that lead to the systems analysis model development by an external vendor. [1] Rational Unified Process®, Version 2003 Copyright © 1987 – 2003. Rational Software Corporation

Scrum Abandonment in Distributed Teams: A Revelatory Case

The last decade has witnessed substantial growth in the adoption of both Agile and distributed software development. However, combining Agile practices, which emphasize regular informal communication, with geographically and temporally distributed sites, which hinder regular informal communication, presents numerous challenges. Proponents of Agile, especially the Scrum project management framework, have published several case studies of successful Scrum implementations in distributed environments. However, few empirical studies examine failed or abandoned Scrum implementations. Consequently, this paper presents a revelatory case study of a geographically and temporally distributed software development team that abandoned its attempted transition to Scrum. Two factors associated with the team’s decision to abandon Scrum are identified – degradation of Scrum practices due to distribution and the undermining of the ScrumMaster’s credibility. Based on this analysis the paper proposes that task/team familiarity, group cohesion and transactive memory may be combined to understand the relationship between geotemporal distribution, process and performance

Facing the Giant: a Grounded Theory Study of Decision-Making in Microservices Migrations

Background: Microservices migrations are challenging and expensive projects with many decisions that need to be made in a multitude of dimensions. Existing research tends to focus on technical issues and decisions (e.g., how to split services). Equally important organizational or business issues and their relations with technical aspects often remain out of scope or on a high level of abstraction. Aims: In this study, we aim to holistically chart the decision-making that happens on all dimensions of a migration project towards microservices (including, but not limited to, the technical dimension). Method: We investigate 16 different migration cases in a grounded theory interview study, with 19 participants that recently migrated towards microservices. This study strongly focuses on the human aspects of a migration, through stakeholders and their decisions. Results: We identify 3 decision-making processes consisting of 22decision-points and their alternative options. The decision-points are related to creating stakeholder engagement and assessing feasibility, technical implementation, and organizational restructuring. Conclusions: Our study provides an initial theory of decision-making in migrations to microservices. It also outfits practitioners with a roadmap of which decisions they should be prepared to make and at which point in the migration.Comment: 11 pages, 7 figure

Black-Box Test Case Generation from TFM Module Interface Specications and Usage Statistics

In this thesis, we propose a black-box testing method that derives important test cases by including usage statistics, and enables a product manager to make a release decision with the rationale, the important use cases specified in the usage statistics are tested and have no error. First, we propose a method to specify components with Trace Function Method (TFM) module interface specifications. Then, we propose a way to associate module usage statistics with the TFM module interface specification. Finally, we propose a method to generate a prioritized list of black-box test cases for component testing and integration testing from the TFM module interface specification with usage statistics

The Oracle Problem in Software Testing: A Survey

Testing involves examining the behaviour of a system in order to discover potential faults. Given an input for a system, the challenge of distinguishing the corresponding desired, correct behaviour from potentially incorrect behavior is called the “test oracle problem”. Test oracle automation is important to remove a current bottleneck that inhibits greater overall test automation. Without test oracle automation, the human has to determine whether observed behaviour is correct. The literature on test oracles has introduced techniques for oracle automation, including modelling, specifications, contract-driven development and metamorphic testing. When none of these is completely adequate, the final source of test oracle information remains the human, who may be aware of informal specifications, expectations, norms and domain specific information that provide informal oracle guidance. All forms of test oracles, even the humble human, involve challenges of reducing cost and increasing benefit. This paper provides a comprehensive survey of current approaches to the test oracle problem and an analysis of trends in this important area of software testing research and practice

The role of knowledge capturing during the elicitation of system requirements in a high-reliability organisation in South Africa

The most important strategic asset in an organisation is the knowledge its employees possesses. As a result, organisations are looking at various methods to retain and understand this knowledge in order to use as competitive advantage. Requirements elicitation is the process where problems that need to be solved, are uncovered. The information that is gathered needs to be analysed, interpreted, modelled and validated before it can be utilised for Information Systems (IS) development. The development of an IS requires access to knowledge, whether the knowledge comes in an explicit or tacit form. Explicit knowledge is knowledge that can be expressed in words or numbers and can be easily articulated. Tacit knowledge is rooted in an individual’s experience and has a personal quality; it is more difficult to articulate and communicate. The extraction of explicit knowledge can be made available with great ease, but there is some degree of tacit knowledge that cannot be encapsulated unequivocally and requires intervention to capture and apply knowledge. The implementation of an IS follows a System Development Life-cycle (SDLC) approach. One of the critical activities in this process is the elicitation of requirements from stakeholders in this interactive process. Elicitation of requirements includes gathering information from users, validating and capturing the information to develop a requirements specification that will be used to develop an IS. The purpose of this interpretive case study was to understand how knowledge can be captured effectively during requirements elicitation in the context of a high-reliability organisation (HRO). An HRO is an organisation that can perform optimally without accidents and have low safety rates over time. An analysis of requirements elicitation in the literature was produced and an online questionnaire was distributed to employees at a HRO in South Africa in order to collect data. Upon analysis of the findings, it was established that employees of this HRO has long tenure at the organisation and is willing to share knowledge. It was also observed that the standard system requirement process does not cater for knowledge capturing as employees at this HRO environment often act based on their own experiences and tacit knowledge rather than explicit knowledge. There is a need to improve on the requirements elicitation process by providing an opportunity for the capturing of this knowledge in the requirements. The document produced after the requirements elicitation, is the software requirements specification document and a recommendation is made that this artefact should cater for the capturing of knowledge.Dissertation (MCom)--University of Pretoria, 2017.InformaticsMComUnrestricte