Raghvinder S. Sangwan

Using RFID tags for tracking patients, charts and medical equipment within an integrated health delivery network

Tracking patients, charts and equipment in hospitals and across integrated health delivery networks is mostly done manually on white boards or manual entry within health information systems. Some health delivery networks have adopted systems using a combination of infrared and radio frequency (RF) technology to help manage the tracking process. This paper proposes an approach that can improve the operational efficiency of a health delivery network by automating this process through the use of RF identification (RFID) tags. RFID tags are low power communication devices that can be embedded in a patients ID bracelet, inside a patient chart and medical equipment, and can help track their location and status.

Cost estimation for global software development

Global software development has gathered pace in recent years. Many software projects now involve asynchronous collaboration among geographically distributed teams several time zones apart. Software costestimation for such projects becomes challenging due to factors such as effort expended in team building and knowledge transfer, creating an architecture of the software product that can be easily distributed and that minimizes cross-site communication, facilitating communication among remote teams collaborating on parts of the architecture that are interrelated and their day-to-day governance.In this paper we structure the additional cost drivers of distributed development and examine the significance of each of these factors as a contributor to the overall cost of a software development project. We suggest ways in which COCOMO II, the most widely used software development cost estimation model, can be tailored to account for these additional complexities.

Test-Driven Development in Large Projects

Test-driven development (TDD) is a key practice for agile developers because it involves writing test cases ahead of the code, which can improve design. The TDD process works well for projects in which a collocated team develops a small to medium system, but it can be challenging for large systems, especially those involving geographically distributed teams. The main obstacle is the degree of integration: when the team must integrate many individual classes developed at distributed sites, the coordination and communication grows exponentially with the number of individual developers and sites. This does not mean that TDD is ineffective for large-scale geographically distributed projects, but developers must take care to account for its focus on unit testing and its failure to rigorously address communications issues during system and integration testing. In this article, suggestions to scale up TDD are presented with two large-scale global software development projects at a major corporation and a recent meeting to exchange global software development best practices with a Fortune 500 company

Integrating a software architecture-centric method into object-oriented analysis and design

The choice of methodology for the development of the architecture for software systems has a direct effect on the suitability of that architecture. If the development process is driven by the users functional requirements, we would expect the architecture to appropriately reflect those requirements. We would also expect other aspects not captured in the functional specification to be absent from the architecture. The same phenomenon is true in development approaches that stress the importance of systemic quality attributes or other non-functional requirements; those requirements are prominent in the resulting architecture, while other requirement types not stressed by the approach are absent. In other words, the final architecture reflects the focus of the development approach. An ideal approach, therefore, is one that incorporates all goals, expectations, and requirements: both business and technical. To accomplish this we have incorporated, into a single architectural development process, generalized Object-Oriented Analysis and Design (OOAD) methodologies with the software architecture-centric method, the Quality Attribute Workshop (QAW) and Attribute Driven Design (ADD). OOAD, while relatively intuitive, focuses heavily on functional requirements and has the benefit of semantic closeness to the problem domain making it an intuitive process with comprehendible results. Architecture-centric approaches, on the other hand, provide explicit and methodical guidance to an architect in creating systems with desirable qualities and goals. They provide minimal guidance in determining fine-grained architecture, however. The integrated approach described in this paper maximizes the benefits of the respective processes while eliminating their flaws and was applied in a eight university, global development research project with great success. A case study from that experiment is included here to demonstrate the method.

Structural Epochs in the Complexity of Software over Time

A case study using a new complexity measurement framework called Structure 101 tracked the structural complexity of three open source software products through their different releases. The analysis found that, as these software products evolved, a large proportion of structural complexity in early releases at the application-code level progressively migrated to higher-level design and architectural elements in subsequent releases, or vice-versa. This pattern repeated itself throughout the evolution of the software product. Refactoring efforts successfully reduced complexity at lower levels, but shifted the complexity to higher levels in the design hierarchy. Conversely, design restructuring at higher levels shifted complexity to lower levels. If this trend holds true for other software products, then mere code refactoring might not be enough to effectively managing structural complexity. Periodic major restructuring of software applications at the design or architectural level could be necessary.

A system for program visualization in the classroom

This paper describes the use of a system which will allow effortless visualization and animation of standard C/C++ programs. The system brings alive programs so that students in CS 1 and CS 2 classes can more easily see each instruction and its effects. They can also see the effects of larger entities such as functions. The system serves as an excellent instructional tool and debugger.

A Visual Interface for Effortless Animation of C/C++ Programs

This paper introduces a software visualization system that (i) creates animations of programs without the programmer writing any animation code, and (ii) provides a window interface that automatically displays program information, explicitly showing the scope and context of its data, and allowing considerable control over animation displays. Programs are specified in textual form but the system creates high-level dynamic displays using bit-mapped graphics and window-interface technology. The dynamics of the displays make a program come to life. The current system was designed primarily for use in CS-I and CS-II courses. Therefore, it assumes that programs will use acyclic linked data structures and relatively small data sets. It provides the programmer no control over the animations and only limited control over the layout. However, we feel this is a reasonable trade-off for the ease of use the system provides.

How Business Goals Drive Architectural Design

This paper illustrates how business goals can significantly impact a software management systems architecture without necessarily affecting its functionality. These goals include 1) supporting hardware devices from different manufacturers, 2) considering language, culture, and regulations of different markets, 3) assessing tradeoffs and risks to determine how the product should support these goals, 4) refining goals such as scaling back on intended markets, depending on the companys comfort level with the tradeoffs and risks. More importantly, these business goals correspond to quality attributes the end system must exhibit. The system must be modifiable to support a multitude of hardware devices and consider different languages and cultures. Supporting different regulations in different geographic markets requires the system to respond to life-threatening events in a timely manner performance requirement.

Architecture leadership and management in globally distributed software development

Globally distributed software development is inherently difficult. The fundamental problem is that communication, coordination and control mechanisms that operate so naturally and invisibly in co-located projects are not available or not as effective for distributed teams. Maintaining a shared up-to-date understanding of the system under design among distributed teams separated by physical, temporal, and cultural distances, therefore, becomes challenging. Under such circumstances the role of a project architect takes on an added significance. The architect must bridge the gaps that exist among the distributed teams especially those with interrelated tasks. Bridging gaps across teams requires proactive effort to create, among distributed teams, a shared level of understanding of the system context, its problem domain and an overarching vision of the system to be designed. We call this a shared project context. Establishing a shared project context goes a long way in creating architectural artifacts, understanding dependencies across software elements of the architecture and the allocation of their development to the distributed teams. Lack of such a context leads to the creation of multiple realities promoting ignorance, confusion and frustration, which subsequently undermine mutual trust and make inter-team communications less effective. This vicious cycle leads to dysfunctional teams, inefficiencies in the project and ultimately to poorly designed architectures.

Adoption of XP practices in the industry—A survey

Agile software development has recently become popular in the software industry. The methodologies in the Agile family are considered to be based on best practices. The most popular approach, Extreme Programming (XP), recommends certain best practices during the requirements gathering, implementation and testing phases of software development. In this paper, the authors analyze the best practices according to data from recent case studies and survey studies to see if and how they are followed. Metaphor was the least used practice, while unit testing was one of the most popular. Most of the practices varied across studies and projects. Agile software development is evolutionary in nature, so customizing the practices is still well within its sounds. Copyright