Microsoft How Builds - Πανεπιστήμιο Πατρώνnikos/mis-ii/papers/cusumano.pdf ·...

MicrosoftBuildsSoftware

Teams of programmers and testers frequently synchronize and periodically stabilize the changes they make to productsin progress, yielding Excel, Office, Publisher, Windows 95,

Windows NT, Word, Works, and more.

Since the mid-1980s, Microsoft and other PC software companies have grad-

ually reorganized the way they build software products in response to quality

problems and delayed deliveries [10]. Many have also found it necessary to

organize larger teams in order to build up-to-date PC software products that

now consist of hundreds of thousands or even millions of lines of source code

and require hundreds of people to build and test over periods of one or more

Michae l A . Cusumano and R ichard W. Se lby

How

COMMUNICATIONS OF THE ACM June 1997/Vol. 40, No. 6 53

years. As the world’s largest producer of PC software,with approximately 20,500 employees, 250 products,and annual revenues of $8.7 billion (fiscal year endingJune 1996), Microsoft has probably tackled more PCsoftware projects than any other company in theindustry. The complexity of some of its products, suchas Windows 95 (which contains more than 11 millionlines of code and required a development team ofmore than 200 programmers and testers), rivals thatof many systems for mainframe computers andtelecommunication systems.

Microsoft’s philosophy for product developmenthas been to cultivate its roots as a highly flexible,entrepreneurial company and not to adopt too manyof the structured software-engineering practicescommonly promoted by such organizations as theSoftware EngineeringInstitute and theInternational Stan-dards Organization[6]. Rather, Microsofthas tried to “scale up”a loosely structuredsmall-team (somemight say hacker)style of product devel-opment. The objectiveis to get many smallparallel teams (threeto eight developerseach) or individualprogrammers to worktogether as a singlerelatively large teamin order to build largeproducts relativelyquickly while stillallowing individualprogrammers and teams freedom to evolve theirdesigns and operate nearly autonomously. Thesesmall parallel teams evolve features and whole prod-ucts incrementally while occasionally introducingnew concepts and technologies. However, becausedevelopers are free to innovate as they go along, theymust synchronize their changes frequently so prod-uct components all work together.

We will summarize how Microsoft uses varioustechniques and melds them into an overall approachthat balances flexibility and structure in softwareproduct development. We are not suggesting thatthe Microsoft-style development approach is appro-priate for all types of software development or thatMicrosoft “invented” these development ideas. Nordo we suggest Microsoft’s software development

methods by themselves have caused the company’sgreat financial success. We are saying there are sev-eral lessons to be learned from how Microsoft buildssoftware products, some of which apply to otherorganizations, some of which do not. Software devel-opers and managers from other organizations candecide which ideas may apply to them after consid-ering such factors as their company’s goals, market-ing strategies, resource constraints, softwarereliability requirements, and development culture.1

Frequent Synchronizations and Periodic StabilizationsWe label Microsoft’s style of product developmentthe “synch-and-stabilize” approach. The essence issimple: Continually synchronize what people are

doing as individualsand as members ofparallel teams, andperiodically stabilizethe product in incre-ments as a project pro-ceeds, rather than onceat the end of a project.Microsoft people referto their techniquesvariously as the “mile-stone,” “daily build,”“nightly build,” or“zero-defect” process.(The term build refersto the act of puttingtogether partiallycompleted or finishedpieces of a softwareproduct during thedevelopment processto see what functions

work and what problems exist, usually by com-pletely recompiling the source code and executingautomated regression tests.) Whatever the label,these techniques address a problem common tomany firms in highly competitive, rapidly changingindustries: Two or three people can no longer buildmany of the new, highly complex products; suchproducts require much larger teams that mustinvent and innovate as they develop the product.Team members need to create components that areinterdependent, but such components are difficult todefine accurately in the early stages of the develop-ment cycle. In these situations, projects must pro-

54 June 1997/Vol. 40, No. 6 COMMUNICATIONS OF THE ACM

1This article is based on the authors’ Microsoft Secrets: How the World’s Most PowerfulSoftware Company Creates Technology, Shapes Markets, and Manages People, The FreePress/Simon & Schuster, New York, 1995.

Without its synch-and-stabilizestructured approach,

Microsoft would probably never havebeen able to design,build, and ship the

products it offers nowand plans to offer

in the future.

ceed byfindingways thatstructureand coordinate what theindividual members dowhile allowing themenough flexibility to becreative and evolve theproduct’s details instages. The developmentapproach must also havea mechanism that allowsdevelopers to test the product with cus-tomers and refine their designs during thedevelopment process.

In a variety of industries, many compa-nies now use prototyping as well as multiplecycles of concurrent design, build, and test activitiesto control iterations as well as to make incrementalchanges in product development [12]. In the soft-ware community, researchers and managers havetalked about “iterative enhancement,” a “spiralmodel” for iteration among the phases in projectdevelopment, and “concurrent development” of mul-tiple phases and activities for the past 20 years [1, 2,3]. However, many companies have been slow to for-mally adopt these recommendations. Nonetheless,the basic idea shared by these approaches is thatusers’ needs for many types of software are so difficultto understand and that changes in hardware and soft-ware technologies are so continuous and rapid, it isunwise to attempt to design a software system com-pletely in advance. Instead, projects may need to iter-ate while concurrently managing many design,build, and testing cycles to move forward towardcompleting a product.

This iterative as well as incremental and concur-rent-engineering style contrasts with a more sequen-tial, or “waterfall,” approach to productdevelopment. In the waterfall approach, projects

seek to “freeze” a product specification, create adesign, build components, and then merge the com-ponents—primarily at the end of the project in onelarge integration and testing phase (see Figure 1). Thisapproach to software development was common in the1970s and 1980s [8]. It also remains a basic model forproject planning in many industries [11]. The water-fall model has gradually lost favor, however, becausecompanies usually build better products if they canchange specifications and designs, get feedback fromcustomers, and continually test components as theproducts are evolving. As a result, a growing numberof companies in software and other industries—including Microsoft—now follow a process that iter-ates among design, building components, and testing,and also overlaps these phases and contains more inter-actions with customers during development. Manycompanies also ship preliminary versions of their prod-ucts, incrementally adding features or functionalityover time in various product releases. In addition,many companies frequently integrate pieces of their


Document No. 1 Software

Requirements

Document No. 2 Preliminary

Design (Spec)

Document No. 4 Final

Design (Spec)

Document No. 6 Final

Design (Spec)

Document No. 6 Operating

Instructions

Document No. 3 Test Plan

Design (Spec)

Document No. 4 Final Design (As Built)

Document No. 5 Test Plan (Spec)

Test Results

Document No. 3 Interface

Design (Spec)

Preliminary Program Design

Software Requirements

System Requirements

Analysis

Program Design

Coding

Testing

Operations. . .

usumano – Figure 1

Figure 1. Waterfall development process model

products together(usually not daily, butoften on a biweekly ormonthly basis). Fre-quent integrationshelp determine whatdoes and does not workwithout waiting untilthe end of the pro-ject—which may beseveral years away.

Strategies andPrinciplesWe observed Micro-soft over a two-and-a-half yearperiod ending mid-1995, con-ducted in-depth interviews with38 key people (including chair-man and CEO Bill Gates), andreviewed thousands of pages ofconfidential project documenta-tion and postmortem reports.Through this research, we identi-fied two strategies for definingproducts as well as developmentprocesses and sets of principlesthat seem critical to making the synch-and-stabilize style of product development.

Microsoft teams begin the process of prod-uct development by creating a “vision state-ment” defining the goals for a new productand orders the user activities that need to besupported by the product features (see Figure2). Product managers (marketing specialists)take charge of this task while consulting pro-gram managers who specialize in writing upfunctional specifications of the product. Theprogram managers, in consultation with devel-opers, then write a functional specification out-lining the product features in sufficient depth to organizeschedules and staffing allocations. But the initial speci-fication document does not try to cover all the detailsof each feature or lock the project into the original setof features. During product development, the teammembers revise the feature set and feature details asthey learn more about what should be in the product.Experience at Microsoft suggests that the feature setin a specification document may change by 30% ormore.

The project managers then divide the product andthe project into parts (features and small featureteams) and divide the project schedule into three orfour milestone junctures (sequential subprojects)

representing completionpoints for major por-tions of the product (seeFigure 3). All the fea-ture teams go through acomplete cycle of devel-opment, feature integra-tion, testing, and fixingproblems in each mile-stone subproject. More-over, throughout anentire project, the fea-ture teams synchronizetheir work by building

the productand by findingand fixingerrors on adaily andweekly basis.At the end of amilestone sub-project, thedevelopers fixalmost all theerrors detected

in the evolving product. These error corrections sta-bilize the product and enable the team to have aclear understanding of which portions of the producthave been completed. The development team maythen proceed to the next milestone and, eventually,to the ship date.

Defining Products and Development ProcessesTo define products and organize the developmentprocess, leading Microsoft product groups follow a


• Vision Statement Product and program management use extensive customer input to identify and priority-order product features. • Specification Document Based on vision statement, program management and development group define feature functionality, architectural issues, and component interdependencies. • Schedule and Feature Team Formation Based on specification document, program management coordinates schedule and arranges feature teams that each contain approximately 1 program manager, 3–8 developers, and 3–8 testers (who work in parallel 1:1 with developers).

Planning Phase Define product vision, specification, and schedule

Program managers coordinate evolution of specification. Developers design, code, and debug. Testers pair with developers for continuous testing. • Subproject I First 1/3 of features (Most critical features and shared components) • Subproject II Second 1/3 of features • Subproject III Final 1/3 of features (Least critical features)

Development Phase Feature development in 3 or 4 sequential subprojects that each results in a milestone release

Program managers coordinate OEMs and ISVs and monitor customer feedback. Developers perform final debugging and code stabilization. Testers recreate and isolate errors. • Internal Testing Thorough testing of complete product within the company • External Testing Thotough testing of complete product outside the company by "beta" sites, such as OEMs, ISVs, and end users • Release preparation Prepare final release of "golden master" disks and documentation for manufacturing

Stabilization Phase Comprehensive internal and external testing, final product stabilization, and ship

Cusumano – Figure 2

Figure 2. Overview of the synch-and-stabilize development approach

strategy we describe as“focus creativity by evolv-ing features and ‘fixing’resources.” Teams imple-ment this strategythrough five specific prin-ciples:

• Divide large projectsinto multiple milestonecycles with buffer time(20%–50% of total projecttime) and no separate productmaintenance group.

• Use a “vision statement” andoutline feature specificationsto guide projects.

• Base feature selection andpriority order on user activi-ties and data.

• Evolve a modular and horizontaldesign architecture, mirroring theproduct structure in the projectstructure.

• Control by individual commitmentsto small tasks and “fixed” projectresources.

These principles are significant forseveral reasons. Employing creativepeople in high-tech companies is cer-tainly important, but directing theircreativity is often more important.Managers can do this by getting devel-opment personnel to think about thefeatures large numbers of customerswill pay money for and by pressuringprojects by limiting the resources, such as staffingand schedule, the company will invest in their devel-opment. Otherwise, software developers risk nevershipping anything to market. This risk is especiallytroublesome in fast-moving industries in whichindividuals or teams have unfocused or highlyvolatile user requirements, frequently change inter-dependent components during a project, or fail tosynchronize their work.

Microsoft gets around these problems by structur-ing projects into sequential subprojects containingpriority-ordered features; buffer time within eachsubproject gives people time to respond to changesand to unexpected difficulties or delays. Microsoftprojects use vision statements and outline specifica-tions rather than detailed designs and complete prod-uct specifications before coding, because teams realize

they cannot determine in advance every-thing developers need to do to build agood product. This approach leavesdevelopers and program managers roomto innovate or adapt to changed orunforeseen competitive opportunities andthreats. Particularly for applicationsproducts, because development teams try

to come up with features that mapdirectly to activities typical cus-tomers perform, the teams need tocarry out continual observation andtesting with users during develop-ment.

Most product designs havemodular architectures allowingteams to incrementally add or com-bine features in a straightforward,

predictable manner. In addi-tion, managers allow teammembers to set their ownschedules, but only after thedevelopers have analyzedtasks in detail (for example,half-day to three-day chunks)and have been asked to per-sonally commit to the sched-ules they set. Managers then“fix” project resources bylimiting the number of peo-ple they allocate to each pro-ject. They also try to limitthe time spent on projects,

especially for applications likeOffice and multimedia prod-ucts, so teams can delete fea-tures if they fall too far

behind. (However, cutting features to save scheduletime is not always possible with operating systems pro-jects in which reliability is more important than fea-tures and in which many features are closely coupledand cannot easily be deleted individually.)

Developing and Shipping ProductsTo manage the process of developing and shippingproducts, Microsoft follows another strategy wedescribe as “do everything in parallel with frequentsynchronization.” Teams implement this strategy byfollowing another set of five principles:

• Work in parallel teams but “synch up” and debugdaily.

• Always have a product you can ship, with ver-sions for every major platform and market.


Development (design, coding, prototyping)

Usability Lab Private Release Testing

Daily Builds Feature Debugging Feature Integration

Code Stabilization (no severe bugs) Buffer time (20%–50%)

Milestone 1 (first 1/3 features)

Milestone 2 (next1/3) Development Usability Lab

Private Release Testing Daily Builds

Feature Debugging Feature Intergration Code Stabilization

Buffer Time

Milestone 3 (last set)Development Usability Lab

Private Release Testing Daily Builds

Feature Debugging Feature IntergrationFeature Complete Code Complete

Code Stabilization Buffer Time

Zero Bug Release Release to Manufacturing

Cusumano – Figure 3

Figure 3. Milestones in the synch-and-stabilize approach (each

taking two to four months)

• Speak a “common language” on a single develop-ment site.

• Continuously test the product as you build it.• Use metric data to determine milestone comple-

tion and product release.

These principles bring considerable discipline tothe development process without the need to controlevery moment of every developer’s day. For example,managers in many different companies talk aboutmaking their companies less bureaucratic, moreinnovative, and faster to react through organizationand process “re-engineering” and “restructuring” tospeed product development. But complex productsoften require large teams of hundreds of people, notsmall teams of a dozen or fewer engineers; and largeteams can make communication and coordinationextremely difficult and slow. Large-scale projects aresimpler to schedule and manage if they proceed withclearly defined functional groups, sequential phases,and precise rules and controls. This approach, how-ever, may restrain innovation and undervalue theimportance of frequently synchronizing work. Com-munication and coordination difficulties across thefunctions and phases may also result in a project’staking more time and people to complete than pro-jects that overlap tasks and require that people share

responsibilities and work in small, nimble teams. What Microsoft tries to do is allow many small

teams and individuals enough freedom to work inparallel yet still function as a single large team, sothey can build large-scale products relatively quicklyand cheaply. The teams also adhere to a few rigidrules that enforce a high degree of coordination andcommunication.

For example, one of the few rules developers mustfollow is that, on whatever day they decide to “checkin,” or enter their pieces of code into the productdatabase, they must do so by a particular time, say, 2p.m. or 5 p.m. This rule allows the project team toassemble available components, completely recom-pile the product source code, and create a new“build” of the evolving product by the end of the dayor by the next morning and then start testing anddebugging immediately. (This rule is analogous totelling children that they can do whatever they wantall day, but they must be in bed at 9 p.m.) Anotherrule is that if developers check in code that “breaks”the build by preventing it from completing therecompilation, they must fix the defect immediately.(This rule resembles Toyota’s famous production sys-tem, in which factory workers are encouraged to stopthe manufacturing lines whenever they notice adefect in a car they are assembling [4].)


Opened/ Resolved

Bugs

1/18 2/1Source: Microsoft internal document

Opened

Resolved

Fixed

Active

19 20 21 22 23 24 25 26 27 28 29 30 31 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Figure 4. Milestone 2: Bug data and daily builds from Excel/Graph

Microsoft’s daily build process has several steps.First, in order to develop a feature for a product,developers can check out private copies of sourcecode files from a centralized master version of thesource code. They implement their features by mak-ing changes to their private copies of the source codefiles. The developers then create a private build ofthe product containing the new feature and test it.They then check in the changes from their privatecopies of the source code files to the master version ofthe source code. The check-in process includes anautomated regression test to help ensure that theirchanges to the source code files do not cause errorselsewhere in the product. Developers usually checkin their code back to the master copy at least twice aweek but may check it in daily.

Regardless of how often individual developerscheck in their changesto the source code, adesignated developer,called the project buildmaster, generates acomplete build of theproduct on a daily basisusing the master ver-sion of the source code.Generating a build for aproduct consists of exe-cuting an automatedsequence of commandscalled a “build script.”This daily build createsa new internal release ofthe product andincludes many stepsthat compile sourcecode. The build processalso automaticallytranslates the sourcecode for a product intoone or more executable files and may create variouslibrary files, allowing end users to customize theproduct. The new internal release of the product builteach day is the daily build. Daily builds are generatedfor each platform, such as Windows and Macintosh,and for each market, such as the U.S., and for themajor international versions.

Product teams also test features as they build themfrom multiple perspectives, including bringing incustomers “off the street” to try prototypes in aMicrosoft usability lab. In addition, nearly allMicrosoft teams work at a single physical site withcommon development languages (primarily C andC++), common coding styles, and standardized

development tools. A common site and common lan-guage and tools help teams communicate, debatedesign ideas, and resolve problems face to face. Pro-ject teams also use a small set of quantitative metricsto guide decisions, such as when to move forward ina project and when to ship a product to market. Forexample, managers rigorously track progress of thedaily builds by monitoring how many bugs are newlyopened, resolved (such as by eliminating duplicates ordeferring fixes), fixed, and active (see Figure 4).

The Hacker ApproachSome people may argue that Microsoft’s key practicesin product development—daily synchronizationthrough product builds, periodic milestone stabiliza-tions, and continual testing—are no more thanprocess and technical fixes for a hacker software orga-

nization now buildinghuge software systems.We do not really dis-agree, but we also thinkthat Microsoft has someinsightful ideas on howto combine structurewith flexibility in prod-uct development. It isworthwhile to note thatthe term hacker is notnecessarily a bad word inthe PC industry. It goesback to the early days ofcomputer programmingin the 1960s, when long-haired, unkempt techni-cal wizards would workat their computers withno formal plans, designs,or processes, and just“bang on a keyboard”and “hack away” at cod-

ing [7]. This approach worked for relatively smallcomputer programs that one person or several peoplecould write, such as the earliest versions of DOS,Lotus 1-2-3, WordPerfect, Word, and Excel. Itbecame unworkable as PC software programs grewinto hundreds of thousands and then millions of linesof code.

Formal plans and processes were first used in themainframe computer industry where software systemshad grown to the million-line-plus size by the end of the1960s [5]. PC software companies have been unwillingto completely give up their traditions and cultures. Norwould it be wise for them to do so, given the rapid paceof change in PC hardware and software technologies


No PC software company has done a better job of keepingsome basic elementsof the hacker culture

while adding justenough structure tobuild today’s, and

probably tomorrow’s, PC software products.

and the need for continual innovation.No company has taken advantage of the exploding

demand for PC software better than Microsoft. Simi-larly, no PC software company has done a better job ofkeeping some basic elements of the hacker culturewhile adding just enough structure to build today’s,and probably tomorrow’s, PC software products. Itcontinues to be a challengefor Microsoft to makeproducts reliable enoughfor companies to buy, pow-erful enough so the prod-ucts’ features solvereal-world problems, andsimple enough for noviceconsumers to understand.To achieve these somewhatconflicting goals for a vari-ety of markets, Microsoftstill encourages someteams to experiment andmake lots of changes with-out much up-front plan-ning. Projects generallyremain under controlbecause teams of program-mers and testers frequentlysynchronize and periodi-cally stabilize theirchanges.

Since the late 1980s,Microsoft has used varia-tions of the synch-and-sta-bilize approach to buildExcel, Office, Publisher, Windows 95, Windows NT,Word, Works, and other products. However, thesynch-and-stabilize process does not guarantee on-time or bug-free products. Creating new, large-scalesoftware products on a precisely predicted scheduleand with no major defects is an extremely difficultgoal in the PC industry. Microsoft and other PC soft-ware companies also try to replace products quicklyand usually announce overly ambitious deadlines,contributing to the appearance of being chronicallylate. Nonetheless, without its synch-and-stabilizestructured approach, Microsoft would probably neverhave been able to design, build, and ship the productsit offers now and plans to offer in the future.

Microsoft resembles companies from many industriesthat do incremental or iterative product development aswell as concurrent engineering. It has also adapted soft-ware-engineering practices introduced earlier by othercompanies (such as various testing techniques) and rein-vented the wheel on many occasions (such as concluding

that accumulating historical metric data is useful foranalyzing bug trends and establishing realistic projectschedules [9]). Microsoft is distinctive, however, in thedegree to which it has introduced a structured hacker-like approach to software product development thatworks reasonably well for both small- and large-scaleproducts. Furthermore, Microsoft is a fascinating exam-

ple of how culture and competitive strategy can driveproduct development and the innovation process. TheMicrosoft culture centers around fervently antibureau-cratic PC programmers who do not like a lot of rules,structure, or planning. Its competitive strategy revolvesaround identifying mass markets quickly, introducingproducts that are “good enough” (rather than waitinguntil something is “perfect”), improving these productsby incrementally evolving their features, and then sell-ing multiple product versions and upgrades to cus-tomers around the world.

A Semblance of OrderThe principles behind the synch-and-stabilize phi-losophy add a semblance of order to the fast-moving,often chaotic world of PC software development.There are no silver bullets here that solve majorproblems with a single simple solution. Rather,there are specific approaches, tools, and techniques;a few rigid rules; and highly skilled people whose


Product development and testing done in parallel Vision statement and evolving specification Features prioritized and built in 3 or 4 milestone subprojects Frequent synchronizations (daily builds) and intermediate stabilizations (milestones) "Fixed" release and ship dates and multiple release cycles Customer feedback continuous in the development process Product and process design so large teams work like small teams

Separate phases done in sequence Complete "frozen" specification and detailed design before building the product Trying to build all pieces of a product simultaneously One late and large integration and system test phase at the project's end Aiming for feature and product "perfection" in each project cycle Feedback primarily after development as inputs for future projects Working primarily as a large group of individuals in a separate functional department

Synch-and-Stablize Sequential Development

Table 1. Synch-and-stabilize vs. sequential development

culture aligns with this approach. As we have sug-gested, several elements distinguish synch-and-sta-bilize from older, more traditional sequential andrigid styles of product development (see Table 1).

Microsoft also has weaknesses. The company nowneeds to pay more attention to, for example, productarchitectures, defect prevention mechanisms, andsome more conventional engineering practices, suchas more formal design and code reviews. New prod-uct areas also pose new challenges for its develop-ment methods. For example, some new areas, such asvideo on demand, have many tightly linked compo-nents with real-time constraints that require precisemathematical models of when video/audio/user datacan be delivered reliably and on time. Many existingand new products have an extremely large or eveninfinite number of potential user conditions or sce-narios to test based on what hardware and applica-tions each customer is using. These new products canbenefit from some incremental changes in the devel-opment process. They also require more advanceplanning and product architectural design thanMicrosoft usually does to minimize problems indevelopment, testing, and operation.

Nonetheless, the synch-and-stabilize processdescribed here provides several benefits for productdevelopers:

• It breaks down large products into manageablepieces (a priority-ordered set of product featuresthat small feature teams can create in a fewmonths).

• It enables projects to proceed systematically evenwhen they cannot determine a complete and sta-ble product design at the project’s beginning.

• It allows large teams to work like small teams bydividing work into pieces, proceeding in parallelbut synchronizing continuously, stabilizing inincrements, and continuously finding and fixingproblems.

• It facilitates competition on customer input,product features, and short development times byproviding a mechanism for incorporating cus-tomer inputs, setting priorities, completing themost important parts first, and changing or cut-ting less important features.

• It allows a product team to be very responsive toevents in the marketplace by “always” having aproduct ready to ship, having an accurate assess-ment of which features are completed, and pre-serving process-product flexibility andopportunism throughout the developmentprocess.These ideas and examples provide useful lessons

for organizations and managers in many industries.The synch-and-stabilize approach used at Microsoftis especially suited to fast-paced markets with com-plex systems products, short lifecycles, and competi-tion based around evolving product features and defacto technical standards. In particular, coordinatingthe work of a large team building many interdepen-dent components that are continually changingrequires a constant and high level of communicationand coordination. It is difficult to ensure that suchcommunication and coordination take place whilestill allowing designers, engineers, and marketingpeople the freedom to be creative. Achieving thisbalance is perhaps the central dilemma that man-agers of product development face—in PC softwareas well as in many other industries.

References

1. Aoyama, M. Concurrent-development process model. IEEE Software 10,4 (July 1993).

2. Basili, V.R., and Turner, A.J. Iterative enhancement: A practical tech-nique for software development. IEEE Trans. Software Eng. SEI-1, 4(Dec. 1975), 390–396.

3. Boehm, B.W. A spiral model of software development and enhance-ment. IEEE Comput. 5 (May 1988), 61–72.

4. Cusumano, M.A. The Japanese Automobile Industry: Technology and Man-agement at Nissan and Toyota. Harvard University Press, Cambridge,Mass., 1985.

5. Cusumano, M.A. Japan's Software Factories: A Challenge to U.S. Manage-ment. Oxford University Press, New York, 1991.

6. Humphrey, W.S. Managing the Software Process, Addison-Wesley, NewYork, 1989.

7. Levy, S. Hackers: Heroes of the Computer Revolution. Anchor/Doubleday,New York, 1984.

8. Royce, W.W. Managing the development of large software systems. InProceedings of IEEE WESCON (Los Angeles, 1970), pp. 1–9.

9. Selby, R.W. Empirically based analysis of failures in software systems.IEEE Trans. Reliab. 39, 4 (Oct. 1990), 444–454.

10. Smith, S.A., and Cusumano, M.A. Beyond the Software Factory: A com-parison of “classic” and “PC” software developers. Working Paper 3607-93/BPS, Sloan School, Massachusetts Institute of Technology, Cam-bridge, Mass., 1993).

11. Urban, G.L., and Hauser, J.R. Design and Marketing of New Products.Prentice-Hall, Englewood Cliffs, N.J., 1993.

12. Wheelwright, S.C., and Clark, K.B. Revolutionizing Product Development.Free Press, New York, 1992.

Michael A. Cusumano ([email protected]) is a professor ofstrategy and technology management in the Sloan School of Man-agement at the Massachusetts Institute of Technology, Cambridge,Mass.Richard W. Selby ([email protected]) is an associate professorof computer science in the Department of Information and Com-puter Science at the University of California, Irvine.

Permission to make digital/hard copy of part or all of this work for personal or class-room use is granted without fee provided that copies are not made or distributed forprofit or commercial advantage, the copyright notice, the title of the publication andits date appear, and notice is given that copying is by permission of ACM, Inc. To copyotherwise, to republish, to post on servers, or to redistribute to lists requires prior spe-cific permission and/or a fee.

© ACM 0002-0782/97/0600 $3.50

c


Microsoft How Builds - Πανεπιστήμιο Πατρώνnikos/mis-ii/papers/cusumano.pdf ·...

Documents

Transcript of Microsoft How Builds - Πανεπιστήμιο Πατρώνnikos/mis-ii/papers/cusumano.pdf ·...