Computing ComputingPractices Practices
Engineering on the Internet for Global Software Production How can Internet technology change software engineering? Fujitsu has taken the first steps in constructing an enterprise-wide, Internet-based infrastructure that allows teams around the world to collaborate on every phase in the life cycle of a global software product.
Jerry Z. Gao San Jose State University
Cris Chen Yasufumi Toyoshima Fujitsu Network Communications Inc.
David K. Leung MagicSoft Consulting Inc.
38
O
ver the past two decades, researchers and tool vendors have introduced techniques and tools to improve software engineering processes. But most of these are host-centered systems with closed architectures, fixed database drivers, specific network requirements, and platform-dependent client and server software. These restrictions make sharing information difficult, complicate tool integration, and limit global user access from diversified software environments. These are the major obstacles in global software production. Today’s Internet technology provides a powerful and cost-effective means of overcoming these obstacles. Internet technologies allow distributed networking, global access, platform independence, information sharing, and internationalization. As others have pointed out, the Internet provides a nearly ubiquitous communication infrastructure, enabling team members to connect to the development process easily.1 Although many large organizations have established enterprise infrastructures on the Internet,2-7 few publications have discussed the issues involved in constructing an Internet-based, global softwareengineering environment. This article reports Fujitsu’s innovative work in this arena. In 1995, a small research and development group within Fujitsu Network Communication Systems developed the first Web-based prototype system to
Computer
support global testing and validation on the company’s intranet.8 Soon after that, the company set up the Product Development Environment project to build an enterprise infrastructure that would offer Internetbased support for the complete life cycle of software products. The primary goal is to establish a software environment that has a configurable system infrastructure and flexible information repositories that support a set of collaborative software tools on a distributed network. Over the past two years, we have developed several systems to work within the PDE infrastructure: a problem information management system (PIMS), a resource management system known as ResourcePark, a test management system (TMS), and an informationsharing system (ISS) for project management. Teams 0018-9162/98/$10.00 © 1998 IEEE
Figure 1. PDE-based global system infrastructure.
Q&A and test team
Development team PDE
PDE Development team
Test team
PDE
Fujitsu-Net Firewall
Development team
Intranet
Extrant-Net
Test team
Firewall
Support team Firewall
PDE
PDE Development team
Marketing team
PDE PDE system Site
Internet Customer
throughout the world have used these systems on the Internet to work on several software product lines.
GLOBAL SOFTWARE ENGINEERING: REQUIREMENTS For a large enterprise such as Fujitsu, developing software can involve several organizations and numerous teams at different locations. Development teams conduct design and implementation; testing teams validate software and test systems; and customer support teams provide various customer services. Each team needs its own environment, tools, and information repositories to support its activities. Nonetheless, the teams need to share and exchange information and software across environments and networks. They also
need to synchronize their workflow and schedules. At the beginning of the PDE project, we studied Fujitsu’s global software production lines and identified a software production model. This model provided a clear picture of how to divide a global software process into engineering functions, managerial functions, and their related support information. It helped us define the scope of the PDE project in a rational way for constructing our virtual software-engineering environment on the Internet.
WEB-BASED INFRASTRUCTURE Figure 1 shows part of the PDE-based system infrastructure for the Fujitsu enterprise. Each site has at least one PDE system, which contains a set of manMay 1999
39
agement systems and tools. Teams on the same site may share or access more than one system in a PDE. To support different user accesses and enforce system security, we divide Internet access into three classes: • Fujitsu-Net. This private intranet serves all of Fujitsu’s internal divisions and departments. Different teams working on the same product line may share information and reuse common software through their PDEs. • Internet. Customers can communicate with customer support teams, marketing, and salespeople over the Internet by accessing a customer support system or a business management system. Because these are public users, we established a rigorous security mechanism and policy. • Extrant-Net. Many global software product lines involve teams from external software workshops or warehouses. Although these teams have their own environments and tools, they need to communicate with Fujitsu teams and share certain information across network firewalls. For example, a Fujitsu validation team might need to monitor the problems, test process, and testing status of an external software-testing team. Meanwhile, an external software developer might need data to check the product problems found by an internal validation group.
Systems According to the software production model, we generated a plan to focus on seven global systems and their information repositories. Business management tracks and manages business information. Its functional scope includes marketing, sales, customer and business tracking, product catalogs, and advertisements. Project information sharing allows us to manage and coordinate the project. This system includes project tracking, news bulletins, schedules, status reports, and cost analyses. For joint projects involving several
teams, project coordination, status sharing, and schedule synchronization are important functions. Resource management controls and manages a global product’s resources including programs, components, scripts, documents, problems, and test cases. This system’s functional scope includes version, release, and document control. Problem management tracks, manages, and shares problems related to a product among various teams globally. This covers problems with bookkeeping, tracking, report and analysis, and notification. Problems can relate to the product itself or to project management. Test management is a Web-based system through which we share test information, manage the testing process, and also report and control tests. Its test agent function helps team members select test cases, control test simulators, manage test tools, and perform autotests. This system not only provides an integrated testing environment but also allows remote testing. Change management is a Web-based global system through which we track, share, manage, and monitor change information. This system tracks changes among different versions of a software product, including requirements and design documents, programs, test cases, and procedures. In addition, it monitors and controls a systematic change process from a change request to design or code changes, as well as document update and test modifications. Customer support is a Web-based multimedia system that helps engineers provide service to customers. It includes customer tracking, call tracking, remote technical support, field support and report, customer questions and answers, customer training, and product distribution. This system provides a remote support capability for customer support engineers and a remote training tool for product trainers.
Information repositories To support these management systems, a PDE system includes several information repositories, as listed in Table 1. Exactly which repositories a PDE includes
Table 1. Repositories hold information that supports PDE system functions. Repository type
Contents
Project information System resource
Schedules, status reports, meeting minutes, deliverables, and team membership Resource database for each software product, each of which contains a product’s version control records, components, program source files, documents, test scripts, and test suites Problem analysis, fixes, validation, and review Test cases, procedures, data, metrics, and reports Customer calls, support, shipping, and training, frequently asked questions and answers, and field support reports User information, including user groups, user accounts, access control settings (for predefined functions in different management systems and tools), and workflow and monitoring information
Problem information Test information Customer information PDE administration
40
Computer
depends on the products under development and the project needs.
PDE SYSTEM ARCHITECTURE A PDE system can support one or more teams on an intranet. As shown in Figure 2, the PDE system has a four-layer architecture. The user interface layer runs on a Web browser. Each system has its own client software, which supports distributed accesses from users. Based on our experience, Java-based client software usually provides a better user interface than HTML-based client software because of Java’s Abstract Window Toolkit features. Although we can use JavaScript in HTMLbased client software to support dynamic tables, dialog boxes, and windows, this option limits the creation of dynamic graphics and complicated windows. On the other hand, Java-based client software usually consumes more system resources. In addition, Java applets
take longer to load than an HTML page. The communication layer is the adopted third-party software, such as a Web server, a CORBA (Common Object Request Broker Architecture) server, or both. This layer controls communications between client software and its corresponding server. When the communication layer uses a Web server, communication between a client and its server follows the HTTP protocol or a secured version of it, such as HTTPS. These protocols support only connectionless communication, which means that both client and server software need packing and unpacking functions to support their communications. This implies that we need a standard communication message format at the application level to support a PDE’s different application functions and systems. Our experience has been that an approach based on CGI script limits concurrent processing and is slower than other approaches, such as CORBA and Remote Method Invocation
Data storage layer Customer databases Change databases Administration databases
Problem databases Database server(s)
Resource databases Test databases
Common database access library
Functional service layer
Product Development Environment (PDE)
Web server
Communication layer
CORBA HTTP
CORBA IIOP Firewall
Intranet
Browser
Browser
Browser
HTML forms/CGI
Java applets/CGI
Java applets/CORBA IIOP
User
User
User
User interface layer
Figure 2. PDE system architecture. May 1999
41
Web server
CORBA System administration
CGI
Service function
CORBA IDL
CGI
Communication interface for administration
CORBA IDL
Communication interface for service function
System-specific components
Security controller User-access controller Workflow process controller System configuration and customization System administration database API
Graphic analysis report generator
E-mail agent
E-mail server
HTML-based report generator
FTP agent
FTP server
Database migration
Database Notification export/import
Repository-specific database API
Database access library Data server
Administration database
Figure 3. Common server architecture. Shaded components are specific to the particular system.
42
(RMI). However, CGI-based approaches are flexible and easy to change, and can be very useful for report generation. With CORBA technology, communication between a client and a server follows the CORBA IIOP protocol, a standard transmission protocol for distributed objects. Compared with RMI, current CORBA technology has the advantages of secured communication and multiple language support. The functional service layer includes several functional servers in the PDE. All these servers can interact with each other through CORBA or an information exchange program in a PDE management system. Each functional server has its own functional scope and specific information repository. To support the interactions and collaborations of distributed objects, CORBA provides the most general solution because it lets objects written in different languages communicate with each other. In addition, a PDE environment needs a management system, which controls and monitors different functional servers and provides a centralized user interface for system administration. The data storage layer consists of three parts: a database access library, including a collection of database access classes or programs; one or more database servers; and logic and physical databases. To cope with
Computer
Specific databases
different database drivers, this layer needs a standardized database definition language. In addition, it requires a related database schema conversion tool and a database migration facility. This four-layer system architecture yields several benefits. Partitioning diversified information into different logic databases increases the PDE system’s scalability, extendability, and performance because one or more database servers can support various data accesses. Grouping various functional servers on the CORBA network increases the flexibility of support for system interactions, system collaborations, and legacy software. Separating the functional service layer from the database access layer increases the flexibility of support for different system configurations and alternative loadbalancing techniques. In addition, it also reduces the impact of software changes in the service functions on the data access programs. Meanwhile, it increases software reuse among a PDE’s systems.
Server architecture A PDE consists of several systems and a group of databases. Each division at one site may set up one or more PDE systems. Although each system in a PDE gives users a distinct set of functional features and information, the PDEs share a set of functional features and
mechanisms. To reduce software development costs— and increase software reuse—we have identified and used a common architecture. As shown in Figure 3, each server in the PDE system includes two parts. System administration. The first part, system administration, consists of the following components and functions: • An interface acts as a communication program between client software for administrators and its corresponding server in a PDE. • The security controller sets up and monitors the system security. • The user-access controller creates and maintains user accounts, groups, and access permissions. • The workflow process controller creates, configures, and maintains a process-oriented workflow according to a state-based workflow model. • System configuration and customization configures or customizes the system-persistent data, parameters, and features according to customer needs. • A system administration database is an application program interface (API) for communication among hardware, software, and users. The systems in a PDE share similar administration functions, but each system has its own user groups, with different access rights to a certain information repository. To achieve system independence and thus increase the PDE’s configuration flexibility, we must give each system its own administration functions. Service function. The second part of a PDE server is its service function, which supports the communications of a specific functional client software and its function server. Both CGI and CORBA can be used here to implement the communication interface. The service function contains the specific components that provide the functions for a particular system. It also contains several components that are common to each system built on the PDE infrastructure. These include report generators for graphic analysis and HTML reports based on data from a database. To access the data, systems must have a component that imports or exports a subset of information from one database to another when both databases have the same database schema. Another common component handles database migration— moving the contents of a database to a newly created database on the same database server. Each system also needs components that act as e-mail and FTP agents. The system must also support three types of notification. Workflow-driven notification is invoked by a workflow process. For example, in a problem management system, when a user enters a problem-fixing record, the system sends a notification message to
testers. Intersystem notification supports the interactions among systems. For example, when a resource management system generates a new product release, it should notify other systems, such as the problem management and test management systems. User-driven notification allows users to send alteration or notification messages to anyone on the Internet. A repository-specific database API provides an interface between a database server and a functional service program.
A standard database access solution is critical to coping with different database drivers.
Client architecture To reduce the software development cost of the PDE project, we identified a common architecture model and used it in our implementation. As shown in Figure 4, this architecture divides client software into six parts. As in the server architecture, the top level of the client architecture is an interface. This client interface can communicate with the server in one of two ways. For systems using CORBA, the interface is a set of distributed interface objects defined in IDL. These systems use the CORBA IIOP as the communication protocol. For systems using Java and CGI script, all communication messages—in both client and server— must use the HTTP protocol. Any client also requires an access controller, which includes components for user access control, security checking, and workflow checking. The loader comprises a data loader and an applet loader. The data loader loads data dynamically from a server to a client. These data are either client-specific or changeable. The applet loader loads Java applets dynamically from a server to a client machine. Although the Java virtual machine (JVM) includes a feature that loads embedded Java applets in HTML pages, we created the applet loader to load other applets during runtime. This is useful for controlling the loading performance and system resources on a client machine. The client data store contains and maintains a set of client-specific data in two folders: persistent data/ objects and dynamic data/objects. Persistent data and objects are a particular user’s information, including account, password, security code, and access control information. Dynamic data and objects are loaded from a function-specific information repository. A typical example in a problem management system would be problem records in a problem database. A utility module, which consists of a set of classes— Help, Print, Tool bar, and Timer—provides basic utilities. System-specific GUI components include GUIs for text and analysis reports, as well as specialized GUIs for other system-specific functions. A GUI for system administration allows an adminMay 1999
43
Figure 4. Common client architecture.
Java/CGI-based communication
Java IDL
Access control Access control
Loader Applet loader
Data loader
Interface Utility Help Print
Security check Workflow check
Client data store Persistent
Dynamic
Tool bar Timer
System-specific GUI components
GUI for system administration
Text report GUI
istrator to manage and maintain user accounts, product releases, and workflow models.
EXPERIENCE AND LESSONS LEARNED Fujitsu began the PDE project in the summer of 1997. Since then, we have developed PIMS, ResourcePark, TMS, and ISS to work within the PDE infrastructure, and teams have used these systems on several global software product lines. We gained valuable knowledge from our practical experience on the PDE project. The following sections summarize the major lessons we have learned.
Design Pay attention to software reuse. Besides creating reusable architecture models for client and server software, we spent a lot of effort finding reusable solutions for features such as workflow, user access control, and system customization for user-defined data. Moreover, we developed other reusable software frameworks, such as a database migration facility and a 2D and 3D Java graphic library for statistical-report generation. These reusable solutions and components have effectively reduced the cost of software development for different systems. Aim at a standardized database access solution. For an enterprise system infrastructure, a standard database access solution is critical for coping with different database drivers and the future evolution of database technology. Achieving this goal requires three actions: 44
Computer
Specificfunction GUI
Analysis report GUI
• Create application database access programs using a standard database access API (such as JDBC, Java Database Connectivity) and a standard database access language (such as SQL, Structured Query Language). This way, you can separate application database access programs from specific database drivers. • Develop an in-house facility that can convert database definitions based on an internal database notation. • Implement an in-house database migration software utility that can move data from one database driver to another based on an internal notation of a database schema. Focus on system customization. Customization features are key to the success of any of the systems in the infrastructure. Ideally, any system in an enterprise infrastructure should support customization for the following features: • • • • •
workflow, user access, user data, report formats, and system selection and configuration.
In our experience, the diverse needs of different teams make the ability to customize these features very important.
Design for scalability. We can look at the scalability of an infrastructure for global software production from three perspectives. The first is functional scalability, the infrastructure’s ability to support an increasing number of functional systems, tools, and services. The second is data scalability, the ability to support an increasing number of data volumes in an information repository. The last is user scalability, the ability to support an increasing number of users. Three actions can help ensure high scalability of an enterprise system infrastructure: • Use one database driver to manage one information repository. This arrangement is more scalable because it avoids the bottleneck of database accesses caused by the growth of data volume in databases and the increase of user numbers in the systems. • Use a dedicated machine for each function server. Also avoid placing a function server and a database server on the same machine. • Find an in-house load-balancing strategy and implement it as a program to handle the most user requests. Doing so is a difficult proposition, and we are currently working on this in our own system.
we came up with several design tips for controlling the system resource requirements of Javabased client software. • Partition a GUI interface into a number of Java applets according to high-level functions. To do so, create a main window to hold a controlling Java applet, which can create separate browser windows to hold function-specific Java applets. This method not only reduces the system loading time, but also cuts the size of the applets. • Focus on class/object reuse and avoid object creation. In one release of the PIMS system, for example, our developers reduced the client software’s system resource usage by 30 to 40 percent after we enforced this rule in GUI design and implementation. • Control the data volume on the client side. For example, use a fixed-size data buffer, control the size of images and icons, reduce the number of colors, and select simple and popular colors. • Effectively use Java’s dispose method to reclaim big objects immediately when they are no longer useful.
The design and implementation of Java applets is key to controlling system resource usage.
Testing Design for system resources. When developing Java-based client software, it is important for developers to consult with customers to determine the system configuration—minimum memory, for example—for client machines. In addition, developers must understand customers’ requirements and system resource limitations for client software. For Java-based client software, system resource usage depends on four factors: • the execution environment—that is, a system’s Web browser and supporting JVM; • the number of Java applets and their sizes in a typical Web browser window; • the volume of data stored in the client software; and • the complexity of GUI components and their structures, including colors, images, icons, and threads. Clearly, the design and implementation of Java applets is key as it affects three of these factors. At the beginning of the PDE project, we did not pay much attention to system resources when designing client software. Later, users found that their 32-Mbyte laptops did not have adequate system resources to run PIMS’s Java applets concurrently with other software. To resolve this problem, developers had to redesign and restructure the applets. Through this experience,
Testing Web-based systems is complicated and costly because of special features such as distributed and concurrent accesses, platform independence, security, and internationalization. A Web-based application usually depends on many different technologies, such as HTML, Java or J++, JavaScript or ActiveX, Web browsers, Web servers, and third-party middleware. This makes it difficult to automate the test process. Although a few test tools are available on today’s market, all have limitations in different areas. Platform testing is important. Because our PIMS system has Java-based client software, we first thought that users would have no problem accessing it through any Java-enabled browser on any platform. We discovered, however, that this was not true after testing it on both PC and Unix platforms using different browsers. At best, a Java applet works well with different browsers except that the hardware differences of the various platforms change its color and size. At worst, a Java applet works fine with one Web browser but has problems with another browser, even on the same client machine. We had a similar experience when upgrading from one browser version to another. Therefore, though tedious, platform testing is necessary to ensure that a Web-based system works well on a specified platform with the required Web browsers. System resource testing is necessary. System resource testing checks the amount of system resources that Java-based client software uses on a given client platMay 1999
45
form. System resources include memory space, swap space, number of threads, and GUI Testers should resources (such as the number of colors and set up a benchmark windows). Each platform has different admintest machine with istration tools that check the system resource usage of a given software application. Because the minimum system of the implementation differences between Web configuration. browsers, it is not surprising that a given Java applet needs different system resources from one Web browser to another—even on the same platform. Our advice to system analysts is to find out early the customer requirements and the minimum system configuration for each type of client machine. Then, testers should use this information to set up a benchmark test machine with the minimum system configuration for each platform. Another tip is to perform system resource testing of your client software as early as possible during system integration and testing. We learned these lessons the hard way. Performance testing is critical, but very expensive and time-consuming. The nature of distributed accesses makes performance testing indispensable for a Webbased application system. Testers should select a target server machine and set up various client machines as a benchmark environment. Ideally, a performance test checks the system performance according to a set of predefined test metrics. For the PIMS system, we used the following categories of test metrics: • user, such as single-user performance or concurrent-user performance; • platform, such as Unix, PC, or portable notebook; and • function, such as problem report, problem analysis, problem display, or problem bookkeeping. To get the detailed performance data about a system, we added a performance-tracking utility to report several aspects of system performance: • download speed for Java applets; • data creation and update speed for client and server programs; • data retrieval speed for client and server programs; • data deletion speed for client and server programs; and • data report speed for client and server programs. This data helps engineers effectively tune system performance. Because of the lack of Web-based automatic test tools, performance testing is time-consuming and tedious. A performance-tracking facility within a system to generate the performance metrics for both 46
Computer
client and server software can significantly reduce performance test cost.
Observations and challenges Although Internet technology has provided powerful, cost-effective tools for constructing our Web-based global software production infrastructure, several challenges and obstacles remain. System performance is critical. For a Web-based application system, system performance depends on many factors. Obviously, network hardware performance is a primary factor. The good news is that vendors are working on faster Internet switching systems using new technology.9 Still, it is up to software developers to choose the most efficient technology, select the optimal algorithm, and write effective programs to reduce the performance overhead of server and client software. For example, at the beginning of the PDE project, we used script-based programs as the communication gateway interface between client and server programs in our PIMS system. Using CGI script resulted in a serious performance problem. We later resolved this problem by using C++ programs. Our system test results indicated that this change improved system performance by 25 to 40 percent. System collaboration and integration is an ongoing concern. An enterprise infrastructure is a collaboration of many systems and tools that work together to support a business function. Business functions will change due to technology updates, product upgrades, new requirements and tools, and structural alterations of existing product lines. System interoperation can be complex. Because a user group may access several systems concurrently, figuring out how these systems interoperate becomes a real issue. For example, a test engineer might want to access test and problem management systems at the same time. To do so, the engineer should only have to log in once. Providing the interoperation, even for a simple login, can be time-consuming. Legacy system support is a necessity. Support for legacy systems can be a determining factor in whether an organization successfully adopts a new enterprise infrastructure. To achieve this support, we can create middleware (or a wrapper program) to connect a legacy system or tool to the infrastructure. Security is always an issue. Because the information for global software production is company proprietary, most information repositories should only be accessible from within the enterprise intranet. Usually, however, a large company’s global software production line involves working with people from outside the company—consultants or other software development houses. In this case, a rigorous security mechanism must control the access of users from outside the company.
F
ujitsu has used Internet technology as a costeffective means of constructing an enterprisewide system infrastructure to aid global software engineering. At this point, we have introduced three of the systems in the PDE environment to several Fujitsu software groups worldwide. Engineers and managers of these groups have used these systems to support a number of global software projects, one of which is a reuse-driven project involving several teams. Our application experience indicates that the infrastructure provides distinct advantages in project management, information sharing, concurrent development, and project coordination. It not only reduces the communication overhead and increases the information sharing; it also enhances the overall process and improves engineering practices. With advances in software reuse and component engineering, there is a strong demand for processes that support domain-specific software reuse and component sharing globally. In the future, an enterprise system infrastructure like PDE may need to add new functional systems and tools to support engineers in component construction, testing, maintenance, and release. ❖
Acknowledgments We thank the members of the R&D group in the Software Engineering Department of the Global Software Technology Division, Fujitsu Network Communications Inc., San Jose, California. We also thank the members of the Global Development Engineering Department in the Operation System Division of Fujitsu Limited, and members of the Software Engineering Department of Fujitsu Hokkaido Communication Systems Limited.
References 1. F. Maurer and G. Kaiser, “Software Engineering in the Internet Age,” IEEE Internet Computing, Sept.-Oct. 1998, pp. 22-24. 2. S. Kamel, “Building an Information Highway,” Proc. 31st Hawaii Int’l Conf. System Science, Vol. 4, IEEE CS Press, Los Alamitos, Calif., 1998, pp. 31-41. 3. W.W. Noah, “The Integration of the World Wide Web and Intranet Data Resource,” Proc. 31st Hawaii Int’l Conf. System Science, Vol. 4, IEEE CS Press, Los Alamitos, Calif., 1998, pp. 496-503. 4. A.W. Biermann, “Toward Every-Citizen Interfaces to the Nation’s Information Infrastructure: A National Research Council Study,” Proc. Fourth Symp. Human Interaction with Complex Systems, IEEE CS Press, Los Alamitos, Calif., 1998. 5. J. Mylopoulos et al., “A Generic Integration Architec-
6.
7.
8.
9.
ture for Cooperative Information Systems,” Proc. First IFCIS Int’l Conf. Cooperative Information Systems, IEEE CS Press, Los Alamitos, Calif., 1996, pp. 208-217. S. Browne et al., “The National HPCC Software Exchange,” IEEE Computational Science & Engineering, Vol. 2, No. 2, Summer 1995, pp. 62-69. J. Wachter, “GEOLIS—Innovative Geoscientific Information Management,” Proc. First IEEE Metadata Conf., IEEE Press, Piscataway, N.J., 1996. J.Z. Gao et al., “Developing an Integrated Testing Environment Using the World Wide Web Technology,” Proc. Compsac 97, IEEE CS Press, Los Alamitos, Calif., 1997, pp. 594-601. S.J. Vaughan-Nichols, “Switching to a Faster Internet,” Computer, Jan. 1997, pp. 31-32.
Jerry Z. Gao is an assistant professor at San Jose State University. His research interests include objectoriented technology, Internet-based software engineering, and software testing and maintenance methodologies. Gao has a PhD and an MS in computer science from the University of Texas, Arlington. He was a manager in the software engineering department of Fujitsu Network Communications Inc. from 1995 to 1998. He is a member of the IEEE.
Cris Chen is a director of the software engineering department of Global Software Technology Division I, Fujitsu Network Communications Inc. His current research interests include software engineering for object-oriented technology and software process management.
Yasufumi Toyoshima is a vice president of Fujitsu Network Communications Inc. His current research interests include software engineering for object-oriented technology and software process management.
David K. Leung is a principal consultant at MagicSoft Consulting Inc. His research interests include software component engineering and distributed computing. Leung has an MS in computer science from the University of Texas, Austin, and a BS in computer engineering from the University of Michigan, Ann Arbor.
Contact Jerry Gao at CISE Dept., Engineering School, San Jose State University, One Washington Square, San Jose, CA 95192-0180;
[email protected] or
[email protected]. May 1999
47
