Balasubramaniam Ramesh
Georgia State University
Network
Latest external collaboration on country level. Dive into details by clicking on the dots.
Publication
Featured researches published by Balasubramaniam Ramesh.
IEEE Transactions on Software Engineering | 2001
Balasubramaniam Ramesh; Matthias Jarke
Requirements traceability is intended to ensure continued alignment between stakeholder requirements and various outputs of the system development process. To be useful, traces must be organized according to some modeling framework. Indeed, several such frameworks have been proposed, mostly based on theoretical considerations or analysis of other literature. This paper, in contrast, follows an empirical approach. Focus groups and interviews conducted in 26 major software development organizations demonstrate a wide range of traceability practices with distinct low-end and high-end users of traceability. From these observations, reference models comprising the most important kinds of traceability links for various development tasks have been synthesized. The resulting models have been validated in case studies and are incorporated in a number of traceability tools. A detailed case study on the use of the models is presented. Four kinds of traceability link types are identified and critical issues that must be resolved for implementing each type and potential solutions are discussed. Implications for the design of next-generation traceability methods and tools are discussed and illustrated.
IEEE Transactions on Software Engineering | 1992
Balasubramaniam Ramesh; Vasant Dhar
Support for various stakeholders involved in software projects (designers, maintenance personnel, project managers and executives, end users) can be provided by capturing the history about design decisions in the early stages of the systems development life cycle in a structured manner. Much of this knowledge, which is called the process knowledge, involving the deliberation on alternative requirements and design decisions, is lost in the course of designing and changing such systems. Using an empirical study of problem-solving behavior of individual and groups of information systems professionals, a conceptual model called REMAP (representation and maintenance of process knowledge) that relates process knowledge to the objects that are created during the requirements engineering process has been developed. A prototype environment that provides assistance to the various stakeholders involved in the design and management of large systems has been implemented. >
decision support systems | 1999
Balasubramaniam Ramesh; Amrit Tiwana
Knowledge centric activities of developing new products and services are becoming the primary source of sustainable competitive advantage in an era characterized by short product life cycles, dynamic markets and complex processes. We view new product development (NPD) as a knowledge-intensive activity. Based on a case study in the consumer electronics industry, we identify problems associated with knowledge management (KM) in the context of NPD by cross-functional collaborative teams. We map these problems to broad Information Technology enabled solutions and subsequently translate these into specific system characteristics and requirements. A prototype system that meets these requirements developed to capture and manage tacit and explicit process knowledge is further discussed. The functionalities of the system include functions for representing context with informal components, easy access to process knowledge, assumption surfacing, review of past knowledge, and management of dependencies. We demonstrate the validity our proposed solutions using scenarios drawn from our case study.
Communications of The ACM | 1998
Balasubramaniam Ramesh
Influencing Requirements Traceability Practice R equirements traceability is viewed as a measure of system quality and is mandated by many standards governing the development of systems (for example, MIL–STD-498). Though the importance and role of traceability in supporting systems development have been long recognized, there are wide variations in the quality and usefulness of the practice [7]. Environmental, organizational, and technical factors influence the implementation of requirements traceability. In this article, we identify and discuss how such influences impact the adoption and use of traceability. The results reported in this article are based on data from a series of empirical studies conducted over four years with the goals of capturing the current practices and trends in requirements traceability, developing reference models to guide improved practice, and understanding the factors that facilitate or impede traceability practice. The primary research question explored in this article is: What are the critical factors that influence the practice of requirements traceability? The study is guided by the theoretical framework for understanding the issues around the adoption of CASE tools developed by Orlikowski [5]. This framework, developed using the grounded theory approach, considers a wide range of factors, including the social context, the motivations and actions of the participants, and the implementation process in systems development. Our adaptation of the basic framework, presented in Figure 1, can be explained in brief as follows: Institutional contexts and the strategic conduct of organizational actors interact over time influencing each other. Balasubramaniam Ramesh Findings from a comprehensive survey identify the major issues that motivate users to employ traceability practices— or not.
Information Systems Journal | 2007
Balasubramaniam Ramesh; Lan Cao; Richard Baskerville
This paper describes empirical research into agile requirements engineering (RE) practices. Based on an analysis of data collected in 16 US software development organizations, we identify six agile practices. We also identify seven challenges that are created by the use of these practices. We further analyse how this collection of practices helps mitigate some, while exacerbating other risks in RE. We provide a framework for evaluating the impact and appropriateness of agile RE practices by relating them to RE risks. Two risks that are intractable by agile RE practices emerge from the analysis. First, problems with customer inability and a lack of concurrence among customers significantly impact agile development. Second, risks associated with the neglecting non‐functional requirements such as security and scalability are a serious concern. Developers should carefully evaluate the risk factors in their project environment to understand whether the benefits of agile RE practices outweigh the costs imposed by the challenges.
European Journal of Information Systems | 2009
Lan Cao; Kannan Mohan; Peng Xu; Balasubramaniam Ramesh
Agile development methodologies such as Extreme Programming are becoming increasingly popular due to their focus on managing time to market constraints and the ability to accommodate changes during the software development life cycle. However, such methodologies need to be adapted to suit the needs of different contexts. Past literature has paid little attention to examine the adaptation of agile methodologies. Using adaptive structuration theory as a lens to analyze data from a multisite case study, we examine how the structure of agile methods, projects, and organizations affect the adaptation of agile methodologies. We describe the various sources of structure that affect appropriation of agile practices, the set of appropriated practices and their characteristics, and their link to process outcomes. Based on our findings, we provide prescriptions for adapting agile development methodologies. We also discuss how adapted agile practices can address several challenges faced by agile development teams.
Requirements Engineering | 1995
Balasubramaniam Ramesh; Timothy Powers; Curtis Stubbs; Michael Edwards
Many standards that mandate requirements traceability as well as current literature do not provide a comprehensive model of what information should be captured and used as a part of a traceability scheme. Therefore, the practices and usefulness of traceability vary considerably across systems development efforts, ranging from very simplistic practices just aimed at satisfying the mandates to very comprehensive traceability schemes used as an important tool for managing the systems development process. We present a case study of a systems development organization, employing a comprehensive view of traceability. A model describing the traceability practice in the organization, perceived benefits of such a scheme and lessons learnt from implementing it are presented.
International Workshop on Software Product-Family Engineering | 2003
Felix Bachmann; Michael Goedicke; Julio Cesar Sampaio do Prado Leite; Robert L. Nord; Klaus Pohl; Balasubramaniam Ramesh; Alexander Vilbig
Effective product family based development depends on exploiting the commonality and variability in customer requirements. The desirability of variability in products is driven by the (manifest and hidden) needs of the various target market segments identified by various organizational units like sales and marketing. These are informed by other critical components of the context in which product families are developed including the technological capabilities, people/human resources available with the organization, the policies and procedures of the organization, and the strategic objective of the organization. Variability Management is seen as the key aspect that differentiates conventional software engineering and software product line engineering [Kruger 02]. Variability in a product family is defined as a measure of how members of a family may differ from each other [WeissLai 99]. Variability is made explicit using variation points. Variation points are places in design artifacts where a specific decision has been narrowed to several options but the option to be chosen for a particular system has been left open [Atkinson 01]. Identification of the points of variability is crucial in proliferating variety from a single product platform. A central component of product family approach is the management of variability. The product family development process involves managing variations among different members of the family by identifying common and variable aspects in the domain under consideration.
decision support systems | 2001
Amrit Tiwana; Balasubramaniam Ramesh
The Internet has led to the widespread trade of digital information products. These products exhibit unusual properties such as high fixed costs and near-zero marginal costs. They need to be developed on compressed time frames by spatially and temporally distributed teams, have short lifecycles, and high perishability. This paper addresses the challenges that information product development (IPD) teams face. Drawing on the knowledge intensive nature of IPD tasks, we identify potential solutions to these problems that can be provided by a knowledge management system. We discuss a prototype Knowledge Management System (KMS) that supports linking of artifacts to processes, flexible interaction and hypermedia services, distribution annotation and authoring as well as providing visibility to artifacts as they change over time. Using a case from the publishing industry, we illustrate how contextualized decision paths/traces provide a rich base of formal and informal knowledge that supports IPD teams.
Annals of Software Engineering | 1997
Balasubramaniam Ramesh; Curtis Stubbs; Timothy Powers; Michael Edwards
Current literature as well as standards that mandate requirements traceability do not provide a comprehensive model of what information should be captured and used as a part of a traceability scheme, leading to wide variation in the quality and usefulness of traceability practice across systems development efforts. In this paper, we present a framework for representing and developing a traceability scheme. The experiences of an organization using traceability as an important component of a quality software engineering process are discussed. Models describing the traceability practice in the organization, as well as issues and lessons learned, both from organizational and technical perspectives, from implementing a comprehensive traceability practice are presented.