Forthcoming in Developing a dynamic, integrative, multi-disciplinary research agenda in E-Commerce/E-Business edited by Steve Elliott, Copyright 2001 IFIP and OCG. Proceedings of the IFIP TC 8 Conference, Salzburg, June 22-23-2001.
eMethodology: Towards a systems development methodology for e-business and e-commerce applications An analysis of three approaches
Richard Baskerville and Jan Pries-Heje Georgia State University
Abstract: The unprecedented growth of the Internet, e-commerce and e-business is threatening to make traditional IS development methodologies obsolete. Based on a case study in three Danish e-application developers, it appears that the present notion of methodology is changing. Traditional IS development methodology is eschewed. The core requirements of eMethodology are time pressure and requirements ambiguity, leading to ten demands. In this paper each of the ten demands is described and three eMethodologies are analysed using the demands framework.
Key words: information systems development, software engineering, Internet, e- commerce, e-business, quality
1. INTRODUCTION
The last decade of the past millennium was filled with people telling us that the world was changing. Critical success factors like time-to-market, customer focus and the ability to respond quickly to changing business needs were often mentioned. In parallel with this the Internet grew from an esoteric academic tool to a commonplace personal appliance. At the same time development cycles "tightened enormously, driven by widespread telecommunications and technical advances in the delivery of software (Beck & Fowler, 2001, p. 21). Thus today the pace of change for e- commerce is blistering. Not only companies have to keep pace with increasing customer volume and expectations, but also they must overtake
1 2 Richard Baskerville and Jan Pries-Heje competitors to satisfy impatient venture capitalists and stockholders. (Kane, Dikel, & Wilson, 2001) Emerging empirical data indicates that the growth of the Internet is unrivalled (Anonymous, 2001). Thus the backbone for an equally incredible growth for e-business and e-commerce now seems to be in place. However, one thing that hasn’t undergone the same revolutionary change is the way software applications are developed. The current concept of IS methodology regards ordered systems development processes and products. Systems development unfolds in a series of phases or stages. Each phase operates with a defined notation and will often result in a prescribed artefact, such as a design document or program. This orderly way of doing things takes time. But when new technologies are penetrating the marketplace at unprecedented speed, then software developers don’t have the time. Simultaneously, software houses that are developing applications for the Internet seem to keep up with the speed, releasing new versions of e- business systems every few months. Therefore we set out to study the needs and requirements of e-commerce development. Our purpose was to understand and describe how e-commerce and e-business application development is carried out in practice, thereby giving input to a discussion of whether the IS development of the past is yielding to a new so-called “eMethodology”. So to formulate our research question, we ask, Is it meaningful to talk about an eMethodology, or is it just more e-hype? Are there eMethodology techniques and practices, or do we just need to apply what we already know about information systems methodology? The paper will be developed as follows. In Section 2, we will describe how we used grounded theory analysis to identify ten demands for a new eMethodology. In section 3 we give an account of the ten demands we have identified. In section 4-6 we will discuss three promising methodology approaches, and finally in section 7 we will discuss our findings and draw some concluding implications from our study and the analysis of the three existing approaches.
2. RESEARCH METHODOLOGY
Our curiosity was aroused when we realized that a large number of software organizations were working at something called “Internet speed” (Cusumano & Yoffie, 1998). At a very general level one could say that we were testing the hypothesis that working at “Internet speed” would change the essential way software development work was organized. But beyond eMethodology: Towards a systems development methodology for e- 3 business and e-commerce applications this we had no hypothesis pre-formulated. We carried out data collection through interviews that followed a semi-structured interview guide. An excerpt from the interview guide is shown in Figure 1.
The Firm & Product & Services Could you tell us about the company? What are your primary products and services? How many people do work here? Demographics Could you tell us a little about yourself and about your work here? Development model Are projects required or supposed to follow a certain development model or set of guidelines? Do projects actually comply? Internet Speed It is often claimed that the pace of development is much higher and the time-to-market much shorter in parts of the IT industry ("Internet Speed"). What is your view on that? What are you doing to increase speed? Are you using any tools in the development? If so, are they then constraining or confining the speed? The development process itself Daily builds? Development releases? Requirements specification? Quality? Talent, learning, training & knowledge Where does knowledge come from? How are people trained? Transfer of knowledge ? To whom? Figure 1: Excerpt from our semi-structured interview guide
We interviewed in three Danish companies in 1999-2000. Two of the companies were new to us and the third was a company we had visited over a period of time for a longitudinal study. The main facts about the three companies are given in Table 1.
Table 1. Facts on the companies studied Company Number of Number of Products Employees Interviewees Gamma 50 4 Custom-tailored Internet products for major international customers Epsilon 40 4 Custom-tailored Internet and Intranet products interfacing with large existing databases. 4 Richard Baskerville and Jan Pries-Heje
Company Number of Number of Products Employees Interviewees Omega 12 2 A general web-based product sold on the market as a standard product for e- commerce.
The interviews at Omega and Epsilon were audio and video recorded. To analyze the data we used grounded theory methodology (Strauss & Corbin, 1990) composed of an alternation between three different coding procedures: open, axial and selective coding. An example of our coding is shown in Figure 2.
Example excerpt from interview at Open Coding EPSILON, May 1999 “[The Development Manager] tried to develop a A Methodology Methodology … but it never really worked. His was developed but starting point was software development. But it not used was the communicative aspects and the design that we never managed. That is what we need to Methodology was integrate … [The development manager’s] missing methodology was only existing in theory. It was communication and not something we used. Thus the methodology was design only a point at the strategic level … Now we have defined a new methodology called Epsilons New methodology application method. This method consists of a defined – with roles project with phases, some actors, and some roles to and actors be filled – such as an architect, a usability person, and a pre-sales person.”
Figure 2: Example of Open Coding
Strauss and Corbin (1990) clearly advocate grounded theory coding of the data until one core category stands out. However, we decided to have two core categories since we found no empirical evidence in the data of a chronological dependence in two central categories. That is, as discussed below, no precedence between time pressure and requirements ambiguity could be established when on Internet speed. Besides the two main categories we identified eight sub-categories. In Figure 3 the relationships between the categories are shown, and in Section 3 of this paper we have given an account of each category and sub-category in the form of demands for a new eMethodology. eMethodology: Towards a systems development methodology for e- 5 business and e-commerce applications 3. DEMANDS FOR AN EMETHODOLOGY
In Baskerville and Pries-Heje (2001), we noted two main categories and eight sub-categories that we have translated into "demands" for a new eMethodology. Each of the demands is briefly described below, along with the chain of causal links that we discovered among these properties. These links help explain why this particular set of properties has come to characterize Internet-time development. These properties and the causal chain are depicted graphically in Figure 3.
Demand for Demand for Have led to Demand for Have led to fluid and ambiguous shortened time negotiating quality requirements Handled by Have led to Handled by Demand for Demand for prototyping Demand for early coding
Requires frequent releases Making it Have led to possible Makes it viable to Demand for parallel development Demand for Demand for structure ? good people Requires May in the future Demand for a fixed lead to architecture
Figure 3. The 10 demands and the relationship between them
3.1 The demand for shortened time
First-to-market is a central, defining high-priority demand of Internet speed development. Minimizing time-to-market from concept to customer use is an all-consuming activity and achievement of this goal drives almost all other elements of the methodology. This goal is not altogether new in business (Smith & Reinertsen, 1995) or in software development (Cusumano 6 Richard Baskerville and Jan Pries-Heje
& Selby, 1995; Iansiti & McCormack, 1997), however, the degree to which it has inflamed widespread systems development methodology has not yet been recognised.
3.2 The demand for fluid and ambiguous requirements
An inability to pre-define system requirements is a central, defining constraint of Internet speed development. The requirements specification that defines the operational goals and strategies in the systems project has traditionally been the heart of systems methodology. However, Internet speed methodology accepts a starting point in which the goals, and consequently the specific strategies, are permitted to persist in near or full ambiguity.
3.3 The demand for prototyping
The idea of using prototypes seems to be widespread and permeating both early and late work in development projects. The use of prototypes seems to be part of the core competence in eMethodology. It is important for visualizing solutions, clarifying vague requirements, and contextualising a new application within an architecture.
3.4 The demand for frequent releases
The vague requirements are not just something we see in the beginning of a project. In fact these continue throughout the projects. One consequence is what we have named a “release orientation”. Software systems are produced in a series of ever more refined and extensive versions of the product; and each release contains bug-fixes and new features. These maturing product cycles characterize major Internet software development in which competition demands significant product and feature changes every few months (Cusumano & Yoffie, 2000, p. 299). Our cases share this release orientation notable in this well-known experience. This release orientation helps relieve some of the time pressure because there always seems to be a new release one or two months ahead. If a feature doesn’t make it for the contemporary release, it is less of a crisis because it can simply be postponed to the following release, which is never very far behind.
3.5 The demand for parallel development
It appears that the release orientation demands a fast cycle time that is impossible to meet in a serial process. Parallel development processes seems eMethodology: Towards a systems development methodology for e- 7 business and e-commerce applications to flourish along with release orientation, meaning that a number of activities take place at the same time. A waterfall-like model is seen as much too slow. Therefore several parallel development processes must be running simultaneously. This means that products and releases have to be designed and co-ordinated for parallel development, another aspect common to large- scale Internet software development (Cusumano & Yoffie, 2000, p. 14).
3.6 The demand for a fixed architecture
To make parallel development possible, it is also necessary to have some organizing framework along which to divide work. We find that this necessity leads to a fixed three-layer architecture in common cases, e.g., a database layer, a business logic layer, and a interface layer. This architecture is used as an important co-ordination mechanism to divide the work in the project.
3.7 The demand for early coding
The short time frame allowed for developing applications also introduces a focus on minimising the time necessary to reach the coding stage. This minimisation of mean-time-to-coding means that hacking becomes acceptable when there is no time to think systematically. The term hacking, in this context, means coding one's way out of a time bind during development.
3.8 The demand for negotiating quality
Quality is a term with widely varying meaning (Crosby, 1980). There are three major perspectives: (1) fulfilment of customer expectations, thus suggesting that quality is the degree of fulfilled expectations; (2) measurable product attributes, defining quality as conformance to requirements; and (3) a good development process will lead to quality. The three resulting kinds of quality can be named expectation-based, product-based, and process-based quality. As a consequence of both time pressure and vague requirements we have found that both product-based and process-based quality gets ignored. However, expectation-based quality, i.e., fulfilling customer and user expectations, is retained. We call this phenomena negotiable quality because quality is implicitly negotiated within a product marketplace where both users and competitors fix quality expectations (Baskerville, Levine, Pries- Heje, Ramesh, & Slaughter, 2001). 8 Richard Baskerville and Jan Pries-Heje 3.9 The demand for good people
Time pressure is the primary reason why good people are in high demand. Qualified employees are a critical bottleneck for Internet speed development. But "good" in this context does not necessarily mean "traditional." For example, programming skills and creativity may be more important than systems analysis skills. To attract such folk, many non- traditional perks are put into place for retaining employees. It might be offering computer games and room to play as mentioned above, or it could be cappuccino machines or pool tables as we have seen in other places when visiting for interviews. On the downside, gold plating (adding things that the customer never asked for) can become a problem when spirited developers autonomously add extra "neat features" to a product.
3.10 The demand for structure?
Structure is an overarching factor that is closely related to methodology and to a number of the demands above. Although the causal relationship cannot be firmly established, there are indications that the older and larger the organization and/or the customers the larger the need for structure. It appears that the breadth of resources available for systems development drives the degree of structure in Internet-time methodology. There seems to be a need for structure, but the traditional structures seem to fail. When resources grow in breadth without structure, quality seems to be driven down, perhaps through ineffective resource use, inefficiency, and poorly coordinated activity. Structure is added almost begrudgingly, and only as little as may be necessary to keep the development activities focused on the goals of fast delivery of desired features.
4. AN ANALYSIS OF THREE APPROACHES
There are a number of methodologies being adapted by organizations involved in Internet speed software development, of which the three selected here are commonly found. Using the demands framework uncovered in our grounded theory analysis, it is possible to discover the degree to which these approaches are currently satisfying the needs of contemporary Internet speed software developers. This analysis is useful to discover what is lacking in the current literature. eMethodology: Towards a systems development methodology for e- 9 business and e-commerce applications 4.1 eXtreme programming
eXtreme programming (XP) is a methodology gaining attention for quick development in an environment that is ill-understood and in which requirements are rapidly evolving. XP was invented by Kent Beck in the mid 1990s and described in several books (Beck, 2000; Beck & Fowler, 2001; Jeffries, Anderson, & Hendrickson, 2001). At the core of XP is a belief that there are four dimensions along which one can improve any software project. These are called the four values: (1) Communication, (2) simplicity, (3) feedback, and (4) courage. For example XP developers communicate with their customers. They strive for a design as simple as possible. They get feedback by testing their software every day. And the courage is for responding courageously to the forever changing requirements in the projects. Thus fluid and ambiguous requirements is a point of departure for XP since it was created in response to problem domains whose requirements change and where customers often don’t have a very good idea of what they want. Thus XP suggests that developers embrace change by selecting a development strategy “… that preserves the most options while actually solving your most pressing problems” (Beck, 2000, p. 38). Another starting point for XP is four control variables of which one is quality, and the others are time, cost and scope. XP believe that “scope provides us the most valuable form of control” (Beck, 2000, p. 15). In the concrete that is done by implementing the most important requirements first “so if further functionality has to be dropped it is less important than the functionality that is already running in the system” (Beck, 2000, p. 19). In relation to quality XP has a very explicit testing strategy: “We will write tests before we code, minute by minute … we will also derive tests from the customer’s perspective” (Beck, 2000, p. 115). Furthermore XP requires the developers to automate as much testing as possible. However, this is all that XP has to contribute towards the demand for (a changed notion of) quality. Thus we find it safe to claim that this demand is only partly covered. “Every release should be as small as possible” (Beck, 2000, p. 56). Thus the demand for frequent releases is definitely fulfilled by XP. In practice XP aims at having a simple design that will run all tests at any given point in the development project. Furthermore XP recommends a practice called continuous integration where you integrate and build the system many times a day, i.e., every time a task is completed (Beck, 2000, p. 54). Therefore one can release a final system at any time any given day! 10 Richard Baskerville and Jan Pries-Heje
Early coding is also a core part of XP. “At the end of the day there has to be a program” and “Code is the one artefact that development absolutely cannot live without” (Beck, 2000, p. 44). So the four basic activities – what people do – in XP are coding, testing, listening (to customers), and designing. To shorten time for development XP includes two practices. One is called refactoring. That is that the programmers always ask if there is a way to change and simplify an existing program – refactor it – instead of writing a new one. The other practice that contributes towards shortening time is the small releases: “Put a simple system into production quickly, then release new versions on a very short cycle” says Beck (2000, p. 54). Furthermore XP insists on 40-hour weeks as opposed to “… young Silicon Valley teams, where long hours are such an important tribal ritual …” (Beck & Fowler, 2001, p. 29). There is no explicit support for prototyping in XP. But of course one could claim that there is no need for prototypes since you can release any time any day. Thus we consider prototyping implicitly covered, also because an important practice in XP is to have on-site customers. “Include a real, live user on the team, available full time to answer questions” recommends Beck (Beck, 2000, p. 54). Architecture plays a minor role in XP. When doing XP you will have a metaphor guiding the development with a simple shared story, but that is about it. So it is safe to claim that XP has no support for the demand for a fixed architecture. The same thing is true for good people and parallel development. There is no specific support or mention of these. On the other hand when planning XP you can decide to have different teams implement different stories in parallel, but since XP is mainly aimed at small teams this issue of concurrency is not addressed. When focusing on the possible demand for structure XP gives some advice for both management and team levels. For example planning and estimation is done in a so-called “planning game,” where one quickly determines the scope of the next release. Estimation is based on small stories (the unit of functionality in XP). For the team, XP defines four roles as essential for the success of an extreme team, namely programmer, customer, coach, and tracker (Beck, 2000, p. 139).
4.2 Adaptive software development
Internet and e-business projects have many characteristics in common with research and development projects, such as high risk and uncertainty. One way to handle projects in this type of environment is Adaptive Software Development – here after coined ASD - (Highsmith, 1999) where you trade eMethodology: Towards a systems development methodology for e- 11 business and e-commerce applications efficiency for speed and flexibility. James Highsmith recommends that this be done by having an adaptive conceptual model that evolves over time. An adaptive development model focuses on iterative phases of development and on (1) speculating, (2) collaborating, and (3) learning. The model also includes an adaptive management model involving, for example, distributed groups and dealing with “high change” since “high speed is easy; high change is the real challenge” (Highsmith, 1999, p. 19). At the core of ASD is iterative development. “An iterative cycle of speculating, collaborating, and learning establishes a framework for adaptation” (page 328). Adaptive iterative cycles are planned using a mission. The cycles are time-boxed and risk-driven. All development work is divided into components and the resulting components are assigned to time-boxes. The important feature of time boxing is not so much the limited time allocated but “… forcing trade-offs and learning in the context of short delivery cycles” (page 88). To plan your mission ASD suggests that you derive a product mission profile. That is a profile where you rate four product quality dimensions – scope, schedule, defects, resources – on a 3-point priority level scale going from “Excel”, over “Improve” to “Accept” (page 67). The idea here is that a project will be organized differently according to the priorities. For example, a project where the schedule is rated “Excel” (such as a fast e- project) will have to be organized rather differently that a project where defect elimination has to “Excel” (such as a zero tolerance military project). Thus a consideration of quality gives input to a mission that is then used to plan the adaptive cycles in the project. Organizational structure as such is not addressed by ASD. But there is a lot of support for team structure and collaboration. It is for example suggested to have a “collaboration facilitator” (page 275) that is thinking about communication in the team all the time. Another element of structure given by ASD is the learning cycle – speculating, collaborating, learning – that is the heart of ASD. Some hostility towards the structure found in CMM is also given. For example it is stated “A level-5 CMM group would not survive long in the rough and tumble world of Internet speed” (page 12). And it is claimed that the structure provided by CMM is good for optimising your development processes but “It is not a wonderful adaptation model” (page 12) as ASD aims to be. Assignment of specific due dates to time-boxes is a techniques that will support the demand for shortened time. Furthermore the division of work into components – “group of things, that are planned and implemented together” (page 84-85) – supports parallel development. In ASD this is called “interactive concurrent development”. Components are developed 12 Richard Baskerville and Jan Pries-Heje concurrently using “partially concluded results from other components” (page 241). Indirectly frequent releases are supported since the ending of a time box gives you a point where you may be able to release something. However, ASD operates with another terminology including three types of iterative loops, called versions, cycles and builds. Versions are what produce a new release of a product. Cycles are where the time boxes are produced delivering a “demonstrable portion” (page 91). And builds “construct an interim portion of the product” (page 91). Fluid and ambiguous requirements are definitely recognized and supported by ASD. “It is impossible to precisely specify software requirements” (page 159). Therefore it is recommended to “communicate through a medium that customers understand” (page 160) namely by showing them an application. The way this should be done is through Customer Focus Groups bringing together developers and customers in a facilitated session, the objective being to document changes to requirements. Prototyping is also implicit in ASD since it is presented as an extension and improvement over Rapid Application Development using prototypes (page 17-18). Also of course the many iterative cycles and the dividing of components into time boxes can be considered prototyping. There is no explicit support for early coding in ASD. In the concrete one will probably start coding earlier with ASD than if guided by a waterfall model, but that is a result of the use of other techniques presented above. Another thing missing in ASD is a recommended or fixed architecture. The same thing is true for good people.
4.3 Web Application Extension For UML
Conallen (1999) offers a popular cookbook approach to web application development by refining, extending and conflating the Rational Unified Process (Kruchten, 1998) and the ICONIX process (Rosenberg & Scott, 1999). The approach is called Web application extension for UML (here after we refer to it as WAE). It is chiefly WAE’s underlying relationship with the Rational Unified Process (RUP) that enables Conallen's approach to meet a number of the demands for an eMethodology. These earlier processes evolved object oriented methodologies. This approach, like the Rational Unified Process, iterates Requirements, Analysis, Design, Implementation, Test and Evaluation until requirements are met and the system is deployed. His approach partly meets the demand for fluid and ambiguous specifications mainly because there are mechanisms in place for changing requirements, and also for tracing requirements (i.e. via RUP and Rational’s Requisite Pro tool). eMethodology: Towards a systems development methodology for e- 13 business and e-commerce applications
WAE is iterative and through its close relationship with the RUP prototyping is also implied. The introductory book about RUP for example has a complete description of how one can build and learn from an architectural prototype (Kruchten 2000, page 240-247). WAE implies the same prototyping-style development, without expressly mentioning it. The expressed reason for iteration is because each phase of the project discovers issues and circumstances that affect decisions made in earlier phases. This iteration process partly supports the demand for renegotiating the requirements and specifications (feature set) and negotiable quality. There is a specification, but it is negotiable. It recognises explicitly the "relative priorities of feature set, time to delivery, acceptable defect count, and so on" (p. 84) as one of the considerations when the methodology tailors itself to the task. For example, when first to market is paramount, QA inspections can be lessened and the ability to change or remove requirements can be increased. Quality is negotiable partly because human-critical Web applications (such as medical and spacecraft) are unlikely in the near future. However, the principles and priorities for negotiation of quality are not specifically given. Although iteration implies that coding can be moved earlier in the process, early coding without any design is unsupported. WAE also mentions the demand for short-time-frame development. The orientation toward feature sets and enabling of first to market strategies (such as the removal of requirements) means that a demand for frequent releases can be met with this approach. Thus the demands for short-time frame and frequent releases are implied by the approach, but not specifically discussed. WAE is aware of the need for good people, by recognizing that team quality will vary. The approach is flexible in permitting the process to adjust according to the proven abilities of the team members. While inexperienced teams need more structure, good people do not need the rigor of an "artifact- laden process" (p. 84). In keeping with its partial roots in the RUP, the approach is architecture centric, thereby solidly supporting a demand for having a fixed architecture, with reference to common architectural patterns such as thin client, thick client and web delivery. Finally, although there is no exclusion, WAE does not cover or mention parallel development in any form.
5. SUMMARY AND CONCLUSION
Table 2 summarizes the analysis of the three selected development approaches in terms of the demands for a new eMethodology. None of the 14 Richard Baskerville and Jan Pries-Heje published software development approaches analysed here appears to satisfy the demands we discovered in our investigation of real-world development settings. However, all three partly satisfy the majority of these demands. There are problematic demands. The demand for good people is not well addressed in any of these methodologies. In addition, negotiable quality and organizational structure are not completely satisfied by any of the three approaches. Demands for early coding and fixed architecture are met in only one of the approaches (XP and WAE respectively).
Table 1. Analysis of eMethodologies and Internet speed development demands. “Y” means the demand is explicitly addressed, “(Y)” means the demand is partly or implicitly addressed, and “N” means that the demand is not addressed. Demands eXtreme Adaptive Software Web Application programming Development Extension of UML Fluid and ambiguous Y Y (Y) requirements Shortened time Y Y (Y) Prototyping (Y) (Y) Y Early coding Y N N Negotiable Quality (Y) (Y) (Y) Frequent releases Y Y (Y) Parallel development N Y N Fixed architecture N N Y Good people N N (Y) Organizational (Y) (Y) (Y) structure
We can see from this analysis that it is meaningful to talk about an eMethodology. This new form of systems development methodology is found in practice. However, the published methodologies have not yet entirely caught up with how these systems must be developed in practice. These approaches are not going to be just more e-hype, they are real and partly used in the wild. It is also clear that there are eMethodology techniques and practices that are distinct from what we already know about information systems methodology. Negotiable quality, early coding, frequent releases, parallel development and a dependency on good people are relatively new and fresh demands in the systems development field.
6. ACKNOWLEDGEMENTS
We are grateful to the three Danish companies that participated anonymously in this study, and to Niels Jørgensen, Roskilde University in Denmark, for his help and participation in collecting the data from Gamma. eMethodology: Towards a systems development methodology for e- 15 business and e-commerce applications 7. REFERENCES
Anonymous. (2001, February 19, 2001). Internet Growing by Leaps and Bytes: Study Says Americans' Trek to Cyberspace Is Now a Stampede. Atlanta Journal Constitution, pp. A1,A9. Baskerville, R., Levine, L., Pries-Heje, J., Ramesh, B., & Slaughter, S. (2001). How Internet Software Companies Negotiate Quality. IEEE Computer, 34(5), 51-57. Baskerville, R., & Pries-Heje, J. (2001). Racing the E-Bomb: How the Internet Is Redefining Information Systems Development Methodology. In B. FitzGerald & N. Russo & J. DeGross (Eds.), Realigning Research and Practice in Is Development: The Social and Organisational Perspective (pp. (Forthcoming)). New York: Kluwer. Beck, K. (2000). Extreme Programming Explained: Embrace Change.: Addison-Wesley. Beck, K., & Fowler, M. (2001). Planning Extreme Programming. Boston: Addison-Wesley. Conallen, J. (1999). Building Web Applications with Uml. Boston: Addison-Wesley. Crosby, P. B. (1980). Quality Is Free: The Art of Making Quality Certain. New York: New American Library. Cusumano, M., & Yoffie, D. (1998). Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft. New York: Touchstone. Cusumano, M., & Yoffie, D. (2000). Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft. New York: Touchstone. Cusumano, M. A., & Selby, R. W. (1995). Microsoft Secrets: How the World's Most Powerful Company Creates Technology, Shapes Markets and Manages People. New York: Free Press. Highsmith, J. (1999). Adaptive Software Development. New York: Dorset House. Iansiti, M., & McCormack, A. (1997). Developing Products on Internet Time. Harvard Business Review, 75(5), 108-117. Jeffries, R., Anderson, A., & Hendrickson, C. (2001). Extreme Programming Installed. Boston: Addison-Wesley. Kane, D., Dikel, D., & Wilson, J. R. (2001). Patterns for Managing the Rhythm of E- Commerce. Cutter IT Journal, 14(1). Kruchten, P. (1998). The Rational Unified Process: An Introduction. Reading, Ma: Addison Wesly Longman. Kruchten, P. (2000). The Rational Unified Process. An Introduction. 2nd Edition. Reading, Massachusetts: Addison-Wesley. Rosenberg, D., & Scott, K. (1999). Use Case Driven Object Modeling with Uml: A Practical Approach. Reading, Ma: Addison Wesley Longman. Smith, P. G., & Reinertsen, D. G. (1995). Developing Products in Half the Time 2nd Edition. New York: Van Nostrand Reinhold. Strauss, A., & Corbin, J. (1990). Basics of Qualitative Research: Grounded Theory Procedures and Techniques. Newbury Park, Calf: Sage. 16 Richard Baskerville and Jan Pries-Heje
8. AUTHOR BIOGRAPHIES
Jan Pries-Heje holds M.Sc. and Ph.D. degrees from Copenhagen Business School, Denmark and is currently visiting professor in Department of Computer Information Systems of Georgia State University. His research interests include information systems development, diffusion and adoption of IT, and software process improvement. Certified ISO 9000 auditor and BOOTSTRAP assessor. Has been project manager for a number of Multi Media and Organizational Change projects. He is the Danish national representative to IFIP Technical Committee 8 on Information Systems. He was conference and organizing chair for the European Conference on Information Systems (ECIS) in Copenhagen, June 1999.
Richard Baskerville holds MSc. and PhD. degrees from the London School of Economics and is department chair and professor of information systems in the Department of Computer Information Systems of Georgia State University. His research specializes in security of information systems, methods of information systems design and development, and the interaction of information systems and organizations. His interest in methods extends to qualitative research methods. He is an associate editor of The Information Systems Journal and MIS Quarterly. Baskerville's practical and consulting experience includes advanced information system designs for the U.S. Defence and Energy Departments. He is a Chartered Engineer under the British Engineering Council.