An Analytical Study of Code Smells

Software development process involves developing, building and enhancing high-quality software for specific tasks and as a consequence generates considerable amount of data. This data can be managed in a systematic manner creating knowledge repositories that can be used to competitive advantage. Lesson\u27s learned as part of the development process can also be part of the knowledge bank and can be used to advantage in subsequent projects by developers and software practitioners. Code smells are a group of symptoms which reveal that code is not good enough and requires some actions to have a cleansed code. Software metrics help to detect code smells while refactoring methods are used for removing them. Furthermore, various tools are applicable for detecting of code smells. A Code smell repository organizes all the available knowledge in the literature about code smells and related concepts. An analytical study of code smells is presented in this paper which extracts useful, actionable and indicative knowledge

Video Game Development in a Rush: A Survey of the Global Game Jam Participants

Video game development is a complex endeavor, often involving complex software, large organizations, and aggressive release deadlines. Several studies have reported that periods of "crunch time" are prevalent in the video game industry, but there are few studies on the effects of time pressure. We conducted a survey with participants of the Global Game Jam (GGJ), a 48-hour hackathon. Based on 198 responses, the results suggest that: (1) iterative brainstorming is the most popular method for conceptualizing initial requirements; (2) continuous integration, minimum viable product, scope management, version control, and stand-up meetings are frequently applied development practices; (3) regular communication, internal playtesting, and dynamic and proactive planning are the most common quality assurance activities; and (4) familiarity with agile development has a weak correlation with perception of success in GGJ. We conclude that GGJ teams rely on ad hoc approaches to development and face-to-face communication, and recommend some complementary practices with limited overhead. Furthermore, as our findings are similar to recommendations for software startups, we posit that game jams and the startup scene share contextual similarities. Finally, we discuss the drawbacks of systemic "crunch time" and argue that game jam organizers are in a good position to problematize the phenomenon.Comment: Accepted for publication in IEEE Transactions on Game

Using Agile Software Development Practices in a Research Oriented Distributed Simulation

Although sometimes controversial, agile methodologies have proven to be a viable choice for some software development projects. Projects suited to agile methodologies are those that involve new technology, have requirements that change rapidly, and are controlled by small, talented teams. Much literature about agile software development leans towards business products and non-government entities. Only a handful of literature resources mention agile software development being used in government contracts and even fewer resources mention research projects. NASA\u27s Airspace and Traffic Operations Simulation (ATOS) is a research oriented simulation that doesn\u27t follow the traditional business project mold. In an effort to gain a better understanding if agile could be used effectively in a NASA contract for a research oriented simulation project, this research looked at what agile practices could be effectively used to help gain simulation reliability while simultaneously allowing routine maintenance, current experiment support, new modeling additions, and comprehensive architectural changes

Automatically Discovering Hidden Transformation Chaining Constraints

Model transformations operate on models conforming to precisely defined metamodels. Consequently, it often seems relatively easy to chain them: the output of a transformation may be given as input to a second one if metamodels match. However, this simple rule has some obvious limitations. For instance, a transformation may only use a subset of a metamodel. Therefore, chaining transformations appropriately requires more information. We present here an approach that automatically discovers more detailed information about actual chaining constraints by statically analyzing transformations. The objective is to provide developers who decide to chain transformations with more data on which to base their choices. This approach has been successfully applied to the case of a library of endogenous transformations. They all have the same source and target metamodel but have some hidden chaining constraints. In such a case, the simple metamodel matching rule given above does not provide any useful information