@article{morrison_pandita_xiao_chillarege_williams_2018, title={Are Vulnerabilities Discovered and Resolved like Other Defects?}, DOI={10.1145/3180155.3182553}, abstractNote={Context: Software defect data has long been used to drive software development process improvement. If security defects (i.e.,vulnerabilities) are discovered and resolved by different software development practices than non-security defects, the knowledge of that distinction could be applied to drive process improvement.}, journal={PROCEEDINGS 2018 IEEE/ACM 40TH INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING (ICSE)}, author={Morrison, Patrick J. and Pandita, Rahul and Xiao, Xusheng and Chillarege, Ram and Williams, Laurie}, year={2018}, pages={498–498} }
 @article{morrison_moye_pandita_williams_2018, title={Mapping the field of software life cycle security metrics}, volume={102}, ISSN={["1873-6025"]}, DOI={10.1016/j.infsof.2018.05.011}, abstractNote={Context: Practitioners establish a piece of software’s security objectives during the software development process. To support control and assessment, practitioners and researchers seek to measure security risks and mitigations during software development projects. Metrics provide one means for assessing whether software security objectives have been achieved. A catalog of security metrics for the software development life cycle could assist practitioners in choosing appropriate metrics, and researchers in identifying opportunities for refinement of security measurement. Objective: The goal of this research is to support practitioner and researcher use of security measurement in the software life cycle by cataloging security metrics presented in the literature, their validation, and the subjects they measure. Method: We conducted a systematic mapping study, beginning with 4818 papers and narrowing down to 71 papers reporting on 324 unique security metrics. For each metric, we identified the subject being measured, how the metric has been validated, and how the metric is used. We categorized the metrics, and give examples of metrics for each category. Results: In our data, 85% of security metrics have been proposed and evaluated solely by their authors, leaving room for replication and confirmation through field studies. Approximately 60% of the metrics have been empirically evaluated, by their authors or by others. The available metrics are weighted heavily toward the implementation and operations phases, with relatively few metrics for requirements, design, and testing phases of software development. Some artifacts and processes remain unmeasured. Measured by phase, Testing received the least attention, with 1.5% of the metrics. Conclusions: At present, the primary application of security metrics to the software development life cycle in the literature is to study the relationship between properties of source code and reported vulnerabilities. The most-cited and most used metric, vulnerability count, has multiple definitions and operationalizations. We suggest that researchers must check vulnerability count definitions when making comparisons between papers. In addition to refining vulnerability measurement, we see research opportunities for greater attention to metrics for the requirement, design, and testing phases of development. We conjecture from our data that the field of software life cycle security metrics has yet to converge on an accepted set of metrics.}, journal={INFORMATION AND SOFTWARE TECHNOLOGY}, author={Morrison, Patrick and Moye, David and Pandita, Rahul and Williams, Laurie}, year={2018}, month={Oct}, pages={146–159} }
 @article{barik_pandita_middleton_murphy-hill_2016, title={Designing for Dystopia Software Engineering Research for the Post-apocalypse}, DOI={10.1145/2950290.2983986}, abstractNote={Software engineering researchers have a tendency to be optimistic about the future. Though useful, optimism bias bolsters unrealistic expectations towards desirable outcomes. We argue that explicitly framing software engineering research through pessimistic futures, or dystopias, will mitigate optimism bias and engender more diverse and thought-provoking research directions. We demonstrate through three pop culture dystopias, Battlestar Galactica, Fallout 3, and Children of Men, how reflecting on dystopian scenarios provides research opportunities as well as implications, such as making research accessible to non-experts, that are relevant to our present.}, journal={FSE'16: PROCEEDINGS OF THE 2016 24TH ACM SIGSOFT INTERNATIONAL SYMPOSIUM ON FOUNDATIONS OF SOFTWARE ENGINEERING}, author={Barik, Titus and Pandita, Rahul and Middleton, Justin and Murphy-Hill, Emerson}, year={2016}, pages={924–927} }
 @inproceedings{pandita_taneja_tung_williams_2016, title={ICON: Inferring temporal constraints from natural language API descriptions}, booktitle={32nd ieee international conference on software maintenance and evolution (icsme 2016)}, author={Pandita, R. and Taneja, K. and Tung, T. and Williams, L.}, year={2016}, pages={378–388} }
 @misc{morrison_pandita_murphy-hill_mclaughlin_2016, title={Veteran developers' contributions and motivations: An open source perspective}, volume={17}, url={http://dx.doi.org/10.1109/VLHCC.2016.7739681}, DOI={10.1109/vlhcc.2016.7739681}, abstractNote={Decades of psychology and sociology research demonstrate that humans change cognitively and socially as they age, so it stands to reason that software developers likewise undergo changes that may affect their work. In this paper, we investigate age-related differences in software developers through the lens of open source software, which is built in communities that tend not to include older software developers. We report on the results of a qualitative panel discussion, then quantitatively analyze such veteran developers' activities on StackOverflow, to understand why few veteran software developers' participate in open source, and how their contributions to software development differ from their younger peers. Our results suggest that veterans' are less motivated by social interactions than their younger peers. Our results also suggest that veterans could contribute a broader knowledge of software development than their younger peers, as well as knowledge of old technologies that can be applied to newer technologies.}, journal={2016 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC)}, publisher={IEEE}, author={Morrison, Patrick and Pandita, Rahul and Murphy-Hill, Emerson and McLaughlin, Anne}, year={2016}, month={Sep}, pages={171–179} }
 @article{johnson_pandita_murphy-hill_heckman_2015, title={Bespoke Tools: Adapted to the Concepts Developers Know}, DOI={10.1145/2786805.2803197}, abstractNote={Even though different developers have varying levels of expertise, the tools in one developer's integrated development environment (IDE) behave the same as the tools in every other developers' IDE. In this paper, we propose the idea of automatically customizing development tools by modeling what a developer knows about software concepts. We then sketch three such ``bespoke'' tools and describe how development data can be used to infer what a developer knows about relevant concepts. Finally, we describe our ongoing efforts to make bespoke program analysis tools that customize their notifications to the developer using them.}, journal={2015 10TH JOINT MEETING OF THE EUROPEAN SOFTWARE ENGINEERING CONFERENCE AND THE ACM SIGSOFT SYMPOSIUM ON THE FOUNDATIONS OF SOFTWARE ENGINEERING (ESEC/FSE 2015) PROCEEDINGS}, author={Johnson, Brittany and Pandita, Rahul and Murphy-Hill, Emerson and Heckman, Sarah}, year={2015}, pages={878–881} }
 @inproceedings{pandita_jetley_sudarsan_williams_2015, title={Discovering likely mappings between APIs using text mining}, DOI={10.1109/scam.2015.7335419}, abstractNote={Developers often release different versions of their applications to support various platform/programming-language application programming interfaces (APIs). To migrate an application written using one API (source) to another API (target), a developer must know how the methods in the source API map to the methods in the target API. Given a typical platform or language exposes a large number of API methods, manually writing API mappings is prohibitively resource-intensive and may be error prone. Recently, researchers proposed to automate the mapping process by mining API mappings from existing code-bases. However, these approaches require as input a manually ported (or at least functionally similar) code across source and target APIs. To address the shortcoming, this paper proposes TMAP: Text Mining based approach to discover likely API mappings using the similarity in the textual description of the source and target API documents. To evaluate our approach, we used TMAP to discover API mappings for 15 classes across: 1) Java and C# API, and 2) Java ME and Android API. We compared the discovered mappings with state-of-the-art source code analysis based approaches: Rosetta and StaMiner. Our results indicate that TMAP on average found relevant mappings for 57% more methods compared to previous approaches. Furthermore, our results also indicate that TMAP on average found exact mappings for 6.5 more methods per class with a maximum of 21 additional exact mappings for a single class as compared to previous approaches.}, booktitle={Ieee international working conference on source code analysis and}, author={Pandita, R. and Jetley, R. P. and Sudarsan, S. D. and Williams, L.}, year={2015}, pages={231–240} }
 @inproceedings{pandita_xiao_zhong_xie_oney_paradkar_2012, title={Inferring method specifications from natural language API descriptions}, DOI={10.1109/icse.2012.6227137}, abstractNote={Application Programming Interface (API) documents are a typical way of describing legal usage of reusable software libraries, thus facilitating software reuse. However, even with such documents, developers often overlook some documents and build software systems that are inconsistent with the legal usage of those libraries. Existing software verification tools require formal specifications (such as code contracts), and therefore cannot directly verify the legal usage described in natural language text in API documents against code using that library. However, in practice, most libraries do not come with formal specifications, thus hindering tool-based verification. To address this issue, we propose a novel approach to infer formal specifications from natural language text of API documents. Our evaluation results show that our approach achieves an average of 92% precision and 93% recall in identifying sentences that describe code contracts from more than 2500 sentences of API documents. Furthermore, our results show that our approach has an average 83% accuracy in inferring specifications from over 1600 sentences describing code contracts.}, booktitle={2012 34th international conference on software engineering (icse)}, author={Pandita, R. and Xiao, X. S. and Zhong, H. and Xie, T. and Oney, S. and Paradkar, A.}, year={2012}, pages={815–825} }
 @inproceedings{pandita_xie_tillmann_halleux_2010, title={Guided test generation for coverage criteria}, DOI={10.1109/icsm.2010.5609565}, abstractNote={Test coverage criteria including boundary-value and logical coverage such as Modified Condition/Decision Coverage (MC/DC) have been increasingly used in safety-critical or mission-critical domains, complementing those more popularly used structural coverage criteria such as block or branch coverage. However, existing automated test-generation approaches often target at block or branch coverage for test generation and selection, and therefore do not support testing against boundary-value coverage or logical coverage. To address this issue, we propose a general approach that uses instrumentation to guide existing test-generation approaches to generate test inputs that achieve boundary-value and logical coverage for the program under test. Our preliminary evaluation shows that our approach effectively helps an approach based on Dynamic Symbolic Execution (DSE) to improve boundary-value and logical coverage of generated test inputs. The evaluation results show 30.5% maximum (23% average) increase in boundary-value coverage and 26% maximum (21.5% average) increase in logical coverage of the subject programs under test using our approach over without using our approach. In addition, our approach improves the fault-detection capability of generated test inputs by 12.5% maximum (11% average) compared to the test inputs generated without using our approach.}, booktitle={2010 ieee international conference on software maintenance}, author={Pandita, R. and Xie, T. and Tillmann, N. and Halleux, J.}, year={2010} }