The Name and Nature of Software Engineering

The nature of software engineering is discussed with particular reference to software-intensive application systems—those whose fundamental purpose is to bring about desired effects in a physical and human problem world by interaction with a programmed machine. Such systems bring together a problem world—which is typically composed of heterogeneous domains, most of which are non-formal—and the formal or semi-formal domain of the machine. A clean engineering separation of the two is rarely, if ever, possible; and attempts to treat the application problem world as an extension of the formal machine are obstructed by its non-formal nature. Software engineers have much to learn from the structure and practices of the established branches of engineering. We must learn from their treatment of formal analysis and reasoning, from their practice of intense specialisation, from their attention to particular instances no less than to general concerns, and—above all—from their reliance on normal artifact design and on normal design disciplines: both are the golden fruit of specialisation

Age of intelligent metering and big data - Hydroinformatics challenges and opportunities

We are at the dawn of a new era of widespread intelligent water metering delivering live consumption data to utilities and consumers in developed nations. As with most new technologies, intelligent metering will follow a type of hype cycle, where initial excitement and great expectation on its benefits is weighed down by disappointment and disillusionment from early adoptions and then strategic enlightenment will prevail and ultimately productive strategic implementation. Fortunately, the conservative nature of the water industry and the challenges of intelligent metering implementation have meant that the excitement never reached fever pitch and the sensible path to strategic enlightenment is being progressed, albeit very slowly. While the large multi-national metering and software companies have created a range of products and software systems for utilities to automatically collect, store and present reports on customer and citywide water consumption data, a plethora of informatics challenges urgently need to be addressed by researchers, engineers, planners and computer scientists to yield the numerous claimed urban water planning, engineering and management opportunities that can be extracted from this big data revolution. If the call to arms to address such challenges can be realised, significant opportunities will surface including water loss reductions, real-time design optimisation of water networks, live online water use tracking and billing, heightened customer satisfaction with the water utility sector, to name a few.Faculty of Science, Environment, Engineering and TechnologyFull Tex

Strategies for protecting intellectual property when using CUDA applications on graphics processing units

Recent advances in the massively parallel computational abilities of graphical processing units (GPUs) have increased their use for general purpose computation, as companies look to take advantage of big data processing techniques. This has given rise to the potential for malicious software targeting GPUs, which is of interest to forensic investigators examining the operation of software. The ability to carry out reverse-engineering of software is of great importance within the security and forensics elds, particularly when investigating malicious software or carrying out forensic analysis following a successful security breach. Due to the complexity of the Nvidia CUDA (Compute Uni ed Device Architecture) framework, it is not clear how best to approach the reverse engineering of a piece of CUDA software. We carry out a review of the di erent binary output formats which may be encountered from the CUDA compiler, and their implications on reverse engineering. We then demonstrate the process of carrying out disassembly of an example CUDA application, to establish the various techniques available to forensic investigators carrying out black-box disassembly and reverse engineering of CUDA binaries. We show that the Nvidia compiler, using default settings, leaks useful information. Finally, we demonstrate techniques to better protect intellectual property in CUDA algorithm implementations from reverse engineering

Case Study On Social Engineering Techniques for Persuasion

There are plenty of security software in market; each claiming the best, still we daily face problem of viruses and other malicious activities. If we know the basic working principal of such malware then we can very easily prevent most of them even without security software. Hackers and crackers are experts in psychology to manipulate people into giving them access or the information necessary to get access. This paper discusses the inner working of such attacks. Case study of Spyware is provided. In this case study, we got 100% success using social engineering techniques for deception on Linux operating system, which is considered as the most secure operating system. Few basic principal of defend, for the individual as well as for the organization, are discussed here, which will prevent most of such attack if followed.Comment: 7 Page

Explainable Software Bot Contributions: Case Study of Automated Bug Fixes

In a software project, esp. in open-source, a contribution is a valuable piece of work made to the project: writing code, reporting bugs, translating, improving documentation, creating graphics, etc. We are now at the beginning of an exciting era where software bots will make contributions that are of similar nature than those by humans. Dry contributions, with no explanation, are often ignored or rejected, because the contribution is not understandable per se, because they are not put into a larger context, because they are not grounded on idioms shared by the core community of developers. We have been operating a program repair bot called Repairnator for 2 years and noticed the problem of "dry patches": a patch that does not say which bug it fixes, or that does not explain the effects of the patch on the system. We envision program repair systems that produce an "explainable bug fix": an integrated package of at least 1) a patch, 2) its explanation in natural or controlled language, and 3) a highlight of the behavioral difference with examples. In this paper, we generalize and suggest that software bot contributions must explainable, that they must be put into the context of the global software development conversation