Software projects produce large quantities of data such as feature requests, requirements, design artifacts, source code, tests, safety cases, release plans, and bug reports. If leveraged effectively, this data can be used to provide project intelligence that supports diverse software engineering activities such as release planning, impact analysis, and software analytics. However, project stakeholders often lack skills to formulate complex queries needed to retrieve, manipulate, and display the data in meaningful ways. To address these challenges we introduce TiQi, a natural language interface, which allows users to express software-related queries verbally or written in natural language. TiQi is a web-based tool. It visualizes available project data as a prompt to the user, accepts Natural Language (NL) queries, transforms those queries into SQL, and then executes the queries against a centralized or distributed database. Raw data is stored either directly in the database or retrieved dynamically at runtime from case tools and repositories such as Github and Jira. The transformed query is visualized back to the user as SQL and augmented UML, and raw data results are returned. Our tool demo can be found on YouTube at the following link:http://tinyurl.com/TIQIDemo.

One of the surprising observations of traceability in practice is the under-utilization of existing trace links. Organizations often create links in order to meet compliance requirements, but then fail to capitalize on the potential benefits of those links to provide support for activities such as impact analysis, test regression selection, and coverage analysis. One of the major adoption barriers is caused by the lack of accessibility to the underlying trace data and the lack of skills many project stakeholders have for formulating complex trace queries. To address these challenges we introduce TiQi, a natural language approach, which allows users to write or speak trace queries in their own words. TiQi includes a vocabulary and associated grammar learned from analyzing NL queries collected from trace practitioners. It is evaluated against trace queries gathered from trace practitioners for two different project environments.

Software traceability is a sought-after, yet often elusive quality in large software-intensive systems primarily because the cost and effort of tracing can be overwhelming. State-of-the art solutions address this problem through utilizing trace retrieval techniques to automate the process of creating and maintaining trace links. However, there is no simple one- size-fits all solution to trace retrieval. As this paper will show, finding the right combination of tracing techniques can lead to significant improvements in the quality of generated links. We present a novel approach to trace retrieval in which the underlying infrastructure is configured at runtime to optimize trace quality. We utilize a machine-learning approach to search for the best configuration given an initial training set of validated trace links, a set of available tracing techniques specified in a feature model, and an architecture capable of instantiating all valid configurations of features. We evaluate our approach through a series of experiments using project data from the transportation, healthcare, and space exploration domains, and discuss its implementation in an industrial environment. Finally, we show how our approach can create a robust baseline against which new tracing techniques can be evaluated.

The study of the extent of ice on Himalayas has been done using data from different passive sensors on board satellites, starting from Nimbus. The Indian satellite OCEANSAT-I carried a microwave passive sensor MSMR operating at different frequencies 6.6, 10.6, 18 and 21 GHz with dual polarization having different spatial resolutions of the order of 150, 75 and 50 km. For study of snow and ice the higher frequency like 37 GHz gives better correlation. Here the study has been done at 18 GHz as 21 GHz frequency is affected by presence of water vapour. The frequency chosen gives the extent of snow/ice in the Himalayan region. The 18 GHz data, over certain location was compared with the data of 6.6 GHz as 6.6 GHz data can penetrate dry snow/ice and so when compared the idea of thickness of snow/ice could be assessed. The brightness temperature measured for vertical polarization is higher as compared to horizontal polarization in both frequencies. This indicates that the surface is smooth. The emissivity for smooth surface gives the variability of brightness temperatures in two different polarizations. Different areas of Himalayas have been chosen for the comparison of brightness temperature at two frequencies they are 6.6 GHz and 18 GHz. It is observed that the temperatures in 18 GHz are different as compared to 6.6 GHz for both V and H polarization. The temperature obtained at 6.6 GHz is not from the surface of ice but from certain depth where the effect of underlying land is observed. The brightness temperature at 18 GHz is mostly from surface which is close to dry ice/snow and so the brightness temperature is lower as compared to that obtained at 6.6 GHz The data for frequency channel 6.6 GHz covers larger grid so frequency channel 10.65 GHz is used for study of snow depth as it provides better results. In this paper the detailed study of Himalayan region at 10.65 GHz and 18 GHz frequencies is presented.