1

Software Engineering軟體工程 簡介

The Software Engineering Discipline

蔡文能交通大學資訊工程學系

tsaiwn@csie.nctu.edu.tw

2

何謂 軟體工程 ?Software Engineering

1968 年秋季， NATO （北約組織）的科技委員會召集了近 50 名一流的程式設計人員、電腦科學家和工業界巨頭，討論和制定擺脫「軟體危機」的對策。在那次會議上第一次提出了軟體工程（ software engineering ）這個概念。

軟體工程是一種用於指導電腦軟體發展和維護的工程學科。

採用工程的概念、原理、技術和方法來開發與維護軟體，應用正確的管理技術與紀律，結合當前最好的技術，使得軟體的發展和維護更有效率，這就是軟體工程。

3

「八二」法則 -- by 社會學家柏雷多 (Pareto)

80% vs. 20% (or 90% vs. 10%) 義大利經濟學家 Vilfredo Pareto( 柏雷多 ) 發現八二法則，

他確認義大利國家 80% 的土地 ( 財富 ) 由 20% 的人口所擁有 ! 國家 80% 的人口被 20% 的人統治 。 80% 的人輸給 20% 的人 ( 賭博 ) 。 股市中只有二成的人是賺錢的，其餘八成

的人是賠錢的 。 企業 80% 的利潤來自 20% 的客戶 ! 80% 的時間花在解決 20% 的問題 。

Why Software Engineering? (1/2)

4

「艾森豪」法則

美國艾森豪將軍指出，人們的精力，往往被緊急但較不重要的事情所佔用，而並未完全或儘可能的將時間與精力用在重要的事。• 「艾森豪」法則的啟示：留多一點時間給重要的事情。• But How ?

Why Software Engineering? (2/2)

5

「艾森豪」法則規劃矩陣

6

The Software Life Cycle Development Use

Modification

Development phase• Analysis• Design• Implementation• Testing

Waterfall model

7

Recent Trends Incremental model Prototyping

• Evolutionary prototyping (use incremental model)• Throwaway prototyping

eXtreme Programming Tools:

• Structure chart, class diagram, UML, collaboration diagram, dataflow diagram, entity-relationship diagram

• CRC CASE tools (Computer Aided Software Engineering)

• Rational ROSE

8

OO tools There are many OO tools for Software Engineering

( 軟體工程 – 計概第六章 ) OOA

• CRC cards (Class-Responsibility-Collaborator) OOD

• Class diagram, UML, Rational ROSE, … OOP

• Languages support OOP: C++, Java, Ada, …

9

OOA: CRC Cards Step two: Write CRC cards and work through scenarios

• Class-Responsibility-Collaborator Cards (Cunningham and Beck)

• Just 3x5 cards

Data fields (attributes) 寫在背面

10

OOD: Object-Oriented Design

Step one: Create a UML class diagram of your objects

Step two: Create a detailed description of the services to be performed

• Peter Coad's "I am a Count. I know how to increment…"

• Activity, sequence, or collaboration UML diagrams

11

Unified Modeling Language

There have been O-O gurus for many years Three of them worked together to define UML (“Three

amigos”: Booch, Rumbaugh, Jacobson) Has now been approved as a standard by the Object

Management Group (OMG) Very powerful, many forms of notation

• It's even provable! (with OCL)

http://www.UML.org

amigos = friends

http://www.omg.org

(Object Constrain Language)

12

So, What is UML?

UML is a Unified Modeling Language UML is a set of notations, not a single methodology Modeling is a way of thinking about the problems using

models organized around the real world ideas. Resulted from the convergence of notations from three

leading Object-Oriented methods:Booch method (by Grady Booch)OMT (by James Rumbaugh)OOSE (by Ivar Jacobson)

You can model 80% of most problems by using about 20% of the UML

UML is a “blueprint” for building complex software

軟體工程師共通的語言

13

History of the UML( http://www.uml.org/ )

PublicFeedback

Web - June 1996 Web - June 1996 UML 0.9UML 0.9

Unified Method 0.8Unified Method 0.8OOPSLA 95OOPSLA 95

UML 1.0UML 1.0UML partnersUML partners

OMG Acceptance, Nov 1997Final submission to OMG, Sept 1997First submission to OMG, Jan 1997

OMG Acceptance, Nov 1997Final submission to OMG, Sept 1997First submission to OMG, Jan 1997

UML 1.1UML 1.1

UML 2.0UML 2.0Approved 2004Approved 2004

Minor revision 1999 Minor revision 1999 UML 1.3UML 1.3

UML 1.4UML 1.4Minor revision 2001Minor revision 2001

OOSEOther methods OMTBooch method

Minor revision 2003Minor revision 2003 UML 1.5UML 1.5

14

UML 常用的 Diagrams

Use case diagrams• Functional behavior of the system as seen by the

user. Class diagrams

• Static structure of the system: Objects, Attributes, and Associations.

Activity diagrams• Dynamic behavior of a system, in particular the workflow,

i.e. a flowchart. Sequence diagrams

• Dynamic behavior between actors and system objects. Statechart diagrams

• Dynamic behavior of an individual object as FSM ( 有限狀態機 ).

15

UML 12 Diagrams

Behavior : • Use Case• Sequence• Collaboration• State Chart• Activity

Structural:• Class• Component• Deployment• Object

Model Management: • Packages (class diagram contains packages)• Subsystems (class diagram contains subsystems)• Models (class diagram contains models)

16

UML Core Conventions

Rectangles are classes or instances Ovals are functions or use cases Types are denoted with non-underlined names

SimpleWatch Firefighter

Instances are denoted with an underlined names myWatch:SimpleWatch Joe:Firefighter

Diagrams are higraphs• Nodes are entities (e.g. classes, states)• Arcs are relationships among entities (e.g. sender/receiver)• Containment represents belonging (e.g. use cases in

package)

Higraphs are an extension to the familiar Directed Graph structure where nodes are connected by edges to other nodes. Nodes represent entities in some domain (in our case, classes, packages, methods, etc.).

17

Use Case Diagram examples

WatchUserWatchRepairPerson

ReadTime

SetTime

ChangeBattery

Actor

Use case

PackageSimpleWatch

Use case diagrams represent the functionality of the systemfrom user’s point of view. ( 強調 what, 但暫不管 how)

A use case documents the interaction between the system user and the system. It is highly detailed in describing what is required but is free of most implementation details and constraints.

18

Class Diagram : a simple Watch

Batteryload()

1

2

Timenow()

PushButtonstatepush()release()

1

1

1

1

1

2

blinkIdxblinkSeconds()blinkMinutes()blinkHours()stopBlinking()referesh()

LCDDisplay

SimpleWatch

Class

Association

Operations

Class diagrams represent the structure of the domain or system

Attributes

Multiplicity

19

Sequence DiagramObject

MessageActivation

Sequence diagrams represent the behavior as interactionsIt shows sequence of events for a particular use case

blinkHours()

blinkMinutes()

incrementMinutes()refresh()

commitNewTime()stopBlinking()

pressButton1()

pressButton2()

pressButtons1And2()

pressButton1()

:WatchUser :Time:LCDDisplay:SimpleWatch

Activation

Collaboration Diagram

Object diagram withnumbered messages

Sequence numbers of messages are nested by procedure call

20

button1&2Pressed

button1&2Pressed

button1Pressed

button2Pressed

button2Pressed

button2Pressed

button1Pressed

button1&2Pressed IncrementMinutes

IncrementHours

BlinkHours

BlinkSeconds

BlinkMinutes

IncrementSeconds

StopBlinking

State chart Diagrams for the watch

StateInitial state

Final state

Transition

Event

FSM: Finite State Machine

21

Activity Diagrams An activity diagram shows flow control within a system

An activity diagram is a special case of a state chart diagram in which states are activities (“functions”)

Two types of states: • Action state:

Cannot be decomposed any furtherHappens “instantaneously” with respect to the level

of abstraction used in the model• Activity state:

Can be decomposed furtherThe activity is modeled by another activity diagram

描述 Business process 或 use case 的操作流程 ; 像流程圖

HandleIncident

DocumentIncident

ArchiveIncident

22

Classes in UML

Classes describe objects• Behaviour (member function signature / implementation)• Properties (attributes and associations)• Association, aggregation, dependency, and inheritance

relationships• Multiplicity and navigation indicators• Role names

Objects described by classes collaborate• Class relations → object relations• Dependencies between classes

23

UML ClassClass name

Data members(attributes)

Instance methods

ArgumentsReturn typesClass method (static)

Data members, arguments and methods are specified byvisibility name : type

Visibility shown as+ public- private# protected

24

Class Attributes

Attributes are the instance data membersand class data members

Class data members (underlined) are shared between all instances(objects) of a given class

Data types shown after ":"

Visibility shown as+ public- private# protected

Attributecompartment

visibility name : type

Class name

+ -

25

Class Operations (Interface)

Operations are the classmethods with their argumentand return types

Public (+) operations define theclass interface

Class methods (underlined) can only access to class datamembers, no need for a classinstance (object)

Operationscompartment

26

Template ( 樣板 ) Classes

Generic classes depending on parametrised types

Type parameter(s)

Operations compartmentas usual, but may havetype parameter instead ofconcrete type

27

Class Inheritance ( 繼承 ; 擴充 )Base class or super class

Derived class or subclass

Arrow shows directionof dependency (B inherits A)

→ B inherits A's interface, behaviour and data members

→ B can extend A, i.e. add newdata members or member functions

→ B depends on A,A knows nothing about B

28

Recommended Book: UML Distilled

Serious O-O designers DO use UML UML Distilled by Martin Fowler is a great practical

introduction to UML Official UML book series published by Addison-

Wesley

http://www.omg.org

29

軟體發展1. 軟體發展計畫 2. 軟體需求規格 3. 軟體設計規格 4. 資料 / 程式對照清單 5. 驗收測試計畫 6. 軟體測試報告 7. 軟體使用手冊8. 系統使用說明會9. 系統發展過程記錄

To Develop a Software System• What features the

customers want?• Scope?• Cost? -- in money,

in time• How can you

measure progress?• Quality?

• MTBF (Mean Time Between Failures) not work

Introduction to

eXtreme Programming

Yet-Shiang Wang, Wen-Nung Tsai

wangys@csie.nctu.edu.tw (汪益賢 )tsaiwn@csie.nctu.edu.tw (蔡文能 )

Department of Computer Science and Information EngineeringNational Chiao Tung University

Introductionto

eXtreme Programming

31

Outline

What is XP(eXtreme Programming) ? Four variables of software development eXtreme Programming(XP) A development episode The basic practices of XP

32

What is XP?

eXtreme Programming(XP) 終極程式設計 –

是由 Kent Beck 於 1995 年提出的一種嚴謹且具有規律的軟題開發方式。

XP 主要包含 12 項核心的實務作法，及幾項相關的配合作法。

XP 是一種新型軟體發展方法，其目的是“在極短的時間內開發出運行良好，而且包含有對使用者而言最有價值的功能軟體”。

eXtreme Programming (XP) : 終極編程

33

Four variables of software development (1/2)

1. Cost2. Time3. Quality4. Scope

The way the software development game is played in this model:• External forces(customers, managers) pick any three of

the variables.• The development team picks the resultant variable.

34

Four variables of software development (2/2)

Some managers and customers believe they can pick the value of all four variables.

"You are going to get all these requirements done by the first of next month with exactly this team. And quality is job one here, so it will be up to our usual standards."

Actually, quality always goes out the window!

35

Analysis of the four variables (1/4)

Cost: • More money can grease the skids a little.• Too much money creates more problems.

Time: • More time to deliver can improve quality and increase

scope.• The constraints generally come from outside, such as

Y2K, the end of the year, and so on.

Nine women cannot make a baby in one month!

36

Analysis of the four variables (2/4)

Quality:• Quality is terrible as a control variable. You can make

very short-term gains by sacrificing quality, but the cost is enormous.

• Often, by insisting on better quality you can get projects done sooner or cheaper.

• There is a human effect from quality. Everybody wants to do a good job, and the work much better if they feel they are doing good work.

37

Analysis of the four variables (3/4)

Scope:• Lots of people know about the cost, time, and quality

as control variables, but don't acknowledge this variable.

• What is valuable about the software under development? Neither the programmers nor the business people have clear ideas.

• Less scope makes high quality possible(as long as the customer's business problem is still solved).

38

Analysis of the four variables (4/4)

Eliminating scope is one of the most powerful decision in project management.

• The scope is a variable that varies a lot.• As soon as the customers see the first release, they

learn what they want in the second release...or what they really wanted in the first.

1) 使用者要求的功能永遠不可琢磨；

2) 開發人員設計的功能永遠不能確定；

3) 軟體發展永遠不會完成。

39

Costs of change (1 /4)

One of the universal assumptions of software engineering is that the cost of change rises exponentially over time.

Cos

t of c

hang

e

Requirement Analysis Design Implementation Test Production

Time

40

Costs of change (2/4)

If the cost of change rising exponentially over time…• You have to pay much more money if you didn't

design well previously.• You would never let a problem get through to

production.• You will try hard to catch problems as soon as

possible.

41

Costs of change (3/4)

If the cost of change rises slowly as asymptote over time, what development strategy will you take?

Cos

t of c

hang

e

Time

42

Costs of change (4/4)

Why can we achieve this goal?• The scope is a variable that varies a lot.• Choose the smallest release that makes the most business

sense. If the cost of change rises slowly as asymptote

over time…• Waiting might be worth more than the value of

investing now.• Business changes are welcome.• Only the highest priority tasks are addressed.

This is a promise of XP!

43

eXtreme Programming (1/2)

What is eXtreme Programming(XP)?• XP is a set of values, principles and practices for

rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible.

• XP is extreme in the sense that it takes 12 well-known software development "best practices" to their logical extremes -- turning them all up to "10". (Code reviews, testing, refactoring, simplicity, and so on)

• XP is based on four core values - communication, simplicity, feedback, and courage.

44

eXtreme Programming (2/2)

Where did XP come from?• XP was originated by Kent Beck,

based on his years of practice.• Kent Beck worked with Ward

Cunningham using the Smalltalk programming language. Smalltalk was the first popular Object-Oriented Programming language.

45

The basic practices of XP The 12 core practices of XP are:

1. The planning game2. Small releases3. System metaphor4. On-site customerS5. Pair programming6. Simple design7. Continuous testing8. Coding standards9. Collective code ownership10. Refactoring11. Continuous integration12. Forty-hour work week

The innovation of XP is:• Putting all these practices under one umbrella.• Making sure they are practiced as thoroughly as

possible.• Making sure the practices support each other to the

greatest possible degree.

46

A development episode

The 8-player Army Chess Game

Customer

Development team

Boss

這是中國大陸客戶對八國軍棋的要求，現在請發表意見。

他們怎麼可以亂改規則？

客戶至上 ! 別抱怨了 , 請估計需要多少時

間完成。沒問題！兩週內完成。

I need help!

請問江先生希望我們在這禮拜有啥進度？

這四點很重要，要先完成。

50

1.The planning game (1/6)

Business and development cooperate to produce the maximum business value as rapidly as possible.1. Business comes up with a list of desired features for

the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required.

2. Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).

3. Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.

51

1.The planning game (2/6)

Write Story: Business can write a new Story at any time. For purpose of the Planning Game, writing a Story just means assigning it a value (in practice, it has to have enough information for Development to assign it a cost).

Estimate Story: Development takes every story and assigns it a cost of 1, 2, or 3 ideal weeks. If the estimate is higher, Business splits the story. (This may result in the story being implemented over more than one Iteration.) If the estimate is lower, Business merges it with another story. (Sometimes we just batch small stories willy-nilly until they add up to at least a week, for estimation purposes. Don't try that at home.) We use a LoadFactor (see ProjectVelocity) of 3 real weeks per ideal week to convert the final schedule to real time.

52

1.The planning game (3/6)

Make Commitment: Business and Development work together to decide what stories constitute the next release and when it will be ready to put into production. There are two ways to drive the commitment, Story Driven and Date Driven.

Story Driven Commitment: Business starts putting the Stories for the next release on the table. As each Story is introduced, Development calculates and announces the release date. This move stops when Business is satisfied that the Stories on the table make sense as the next release.

Date Driven Commitment: Business picks a release date. Development calculates and announces the cumulative cost of Stories they can accomplish between now and the date. Business picks Stories whose cost adds up to that number.

53

1.The planning game (4/6) Value and Risk First: Development orders the

Stories in a commitment so: 1. A fully working but sketchy system is completed

immediately (like in a couple of weeks) 2. More valuable Stories are moved earlier in the

schedule (BusinessValueFirst) 3. Riskier Stories are moved earlier in the schedule

(WorstThingsFirst)

54

1.The planning game (5/6) Overcommitment Recovery: Development had predicted

they could do 150 units of stories between now and the deadline. Based on measuring ProjectVelocity, they find and immediately announce that they can only do 100. Business selects the 100 units of Stories to retain, deferring the other Stories to a future release. (Or highly unlikely: Business decides to defer the deadline to get the extra 50 units done.)

Change Value: Business changes the value of a Story. In response, Development may change the order of Stories not yet completed.

Introduce New Story: Business writes a new Story. Development estimates it. Business defers Stories in the current Commitment whose cumulative cost is the cost of the new Story. Development re-evaluates Value and Risk First.

55

1.The planning game (6/6) Split Story: Business splits a Story into two or more.

Business assigns a value to each, and Development assigns a cost to each. Typically this is done because resources do not permit the whole story to be done soon enough.

Spike: Business can divert Project resources to do a throwaway Spike to fight a fire or prove a concept. If this Spike is anything more than a temporary fix, Business makes a UserStory to account for it. That Story is scheduled according to Value And Risk First. Regular spikes, especially fire-fighting ones, will affect the LoadFactor.

Re-estimate: Development estimates the remaining stories in the Commitment again. This can spark an OvercommitmentRecovery.

56

57

2.Small releases, Frequent Releases

Start with the smallest useful feature set. Release early and often, adding a few feature

each time. SmallReleases are a core practice of Xp. Each

cycle is very short and you only provide the code for a very small set of functionality (e.g. you only implement a few UserStories each cycle).

小量發行(Small Releases)

頻繁的發行 (Frequent Releases)

58

3.System metaphor Each project has an organizing metaphor, which

provides an easy way to remember naming convention.

A simple shared story of how the system works. This story typically involves a handful of classes and patterns that shape the core flow of the system being built.

Ask yourself, what more familiar things is this problem like? Is it really like ordering coffee from a fancy coffee machine? Is it really mostly like steering (tacking) a sailboat across a lake? driving from Toronto to Paris?

59

4.On-site customer

Development team has continuous access to a real live customer, that is, someone who will actually be using the system.

A real customer must sit with the team, available to answer questions, resolve disputes, and set small-scale priorities.

For commercial software with lots of customers, a customer proxy(usually the product manager) is used instead.

你現在有空可以「和」我一起寫

八國軍棋嗎？

赴湯蹈火，在所不辭！

61

5.Pair programming (1/3) All production code is written by two programmers

sitting at one machine. Essentially, all code is reviewed as it is written. Each member performs the action the other is not

currently doing: While one types in UnitTests the other thinks about the class that will satisfy the test, for example.

在理想的 XP專案當中，開發者是成對的工作，而且也不是靜態的成對：依據哪些事要做而誰知道怎麼做，人們可能變換伙伴一天好幾次。這個想法；當然是立基於格言「兩個頭腦比一個好 (two heads are better than one) 」。

62

5.Pair programming (2/3) You have several people working on a project.

Everyone's received the basic training necessary to do the job. Some are (inevitably) more or less experienced than others.

You want to get more done than your most productive person can do. You want your less experienced people to learn from your more experienced people.

When applicable, each pair should have a relatively experienced and a relatively inexperienced person. For work being done at a computer, put the relatively inexperienced person at the keyboard, so everything the experienced person says has to flow through the novice to the computer.

63

這個 for loop 要這樣寫才對…

這裡要用synchronized，因為可能會有同步問題。

64

我看不下去了！這樣子寫 for loop 比較漂亮，而且有效率。

學長，請問你有沒有空和我一起加

強八國軍棋的 AI 。

沒在怕的啦！憑我對四國軍棋的經驗，我可以教妳幾招。

八國軍棋的 AI? 歹勢，我不行

了！

66

5.Pair programming (3/3)

One programmer designs, the other one does the programming.

Both programmers can get control of the keyboard and mouse.

Pair programming can• Improves Design quality• Reduces defects, staffing risk• Enhances technical skills• Be considered more enjoyable.

Some research shows that the additional development cost for these benefits is not the 100%, but is approximately 15%.

67

Costs of pair programming

After the first program, together the pairs only spent about 15% more time on the program than the individuals.

Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs.

68

Benefits of pair programming (1/2)

The resulting code has about 15% fewer defects.

69

Benefits of pair programming (2/2)

The pairs implemented the same functionality as the individuals in fewer lines of code.

70

能夠直接轟炸的飛彈，應該要一個新的

class 。

要不要做出防空飛彈啊？

我想事先設計出可以轟炸好幾格的飛彈 class 。

我花了整整一天做的超強飛彈系統功能不要了？

別抱怨，客戶至上。

72

6.Simple design

Always use the simplest possible design that gets the job done.

The requirements will change tomorrow, so only do what's needed to meet today's requirements.

Put in what you need when you need it. Doing that which does not have

BusinessValue is wasteful.

KISS = Keep It Simple and Stupid

73

先把所有棋子翻開，待會要這樣子測試飛彈。

74

7.Continuous testing

1. Before programmers add a feature, they write a test for it. When the suite runs, the job is done.

2. Tests in XP come in two basic flavors.• Unit tests are automated tests written by the developers to

test functionality as they write it.• Functional tests are specified by the customer to test that

the overall system is functioning as specified.

3. When all the functional tests pass for a given user story, that story is considered complete.

Ideally functional tests should be automated

這樣比較好！

這樣比較好！

76

8.Coding standards Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who

on the team has touched a specific piece of code. Projects benefit from having strong Coding

Conventions/Standards because... • People can stop reformatting code and renaming variables

and methods whenever working on code written by other people.

• It's slightly easier to understand code that is consistently formatted and uses a consistent naming standard.

• It's easier to integrate modules that use a common consistent naming standard -- less need to look up and cross-reference the different names that refer to the same thing.

Coding Standard and ConventionDiscipline ( 紀律 )

Coding style is much like writing style. No two people are going to have the exact same style, so don't kill yourself over it. Instead, strive to achieve uniformity through mutual agreement.

77

水啦！俘虜到對手的飛彈了！

飛彈不能俘虜，這應該是bug啦！

78

看！這個飛彈的class怎麼會繼承總司令，難怪會被俘虜。

這是 ChessBase 的錯，那八國軍棋應該也掛了。把這個 bug

修一修吧。

這裡的 code很亂，應該重整一下。

79

9.Collective code ownership

No single person "owns" a module. Any developer is expect to be able to work on any

part of the codebase at any time. The ability to make this work requires at least:

• all engineers use the same CodingStandards; • code management tools to detect and resolve

conflicts (CVS!); • a comprehensive suite of UnitTests to ensure

quality; • powerful browsing and RefactoringTools to find

references to old methods and replace them with the new;

• ContinuousIntegration (or nearly that) so that conflicts are rare (also CVS).

80

10.Refactoring

Refactor out any duplicate code generated in a coding session.

You can do this with confidence that you didn't break anything because you have the tests.

Refactor Mercilessly (無情的重組 ) • When you find two methods that look the same, you

refactor the code to combine them. • When you find two objects with common

functionality, you refactor to make there be just one.

81

先把所有棋子翻開，待會要這樣子測試飛彈。

不，改之前，先checkout 一下

最新版本。

開始實作炸彈的 class 。

82

11.Continuous Integration

All changes are integrated into the codebase at least daily.

The tests have to run 100% both before and after integration.

Conventional code management systems use techniques like check-in/check-out to help you be sure you're working on the current version when you edit something.

Peruse Source Code Control: CVS

83

12.Forty-hour work week

OverTime is time spent in the office when you don't want to be there.

Programmers go home on time. In crunch mode, up to one week of overtime is

allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.

I believe that there are many bright, young, unattached programmers who would only go home and hack on their home computers if they left work, so they just stay at work instead.

Do you live to work? or do you work to live?

The planning game

Small releases

System metaphor

Simple design

Continuous testing

Refactoring

Pair programming

Collective code ownership

Continuous integration

40-hour work week

On-site customer

Coding standards

85

References

Kent Beck, "Extreme Programming Explained," Addison-Wesley Pub Co; 1st edition(October 5, 1999), ISBN:0201616416

Extreme Programming Resource, http://www.xprogramming.com

If you can't win, don't fight If you can win, fight only if it's worth the cost

86

分析：「 XP 」能否進行大規模軟體發展發佈時間： 2001-07-04 15:51:56 來源：日經 BP 社　在大型軟體發展項目中不能夠使用「 XP 」嗎？ --將最近有關 XP 的報導整理

一下，首先就會產生這麼一個疑問。

　　 XP 是一種新型軟體發展方法，其目的是“在極短的時間內開發出運行良好，而且包含有對使用者而言最有價值的功能軟體”。　　 XP本質上是「開發小組」導向的開發方法。說到開發小組，少則應該有 2～ 3 人，多則可達到 15 人左右。對於需要 50 人、 100 人或者更多技術精英的開發專案，很多人認為 XP 就不能使用了。因此， (至少幾個月前 )大型電腦製造商和大型系統集成商就異口同聲地表示：「 XP畢竟是小型專案導向的開發方法。作為以大型專案為核心業務的大公司，將不會採用這種方法」。

不過，大型企業的「 XP= 開發小組的方法 =與 (以大專案為核心的 )公司無關」的邏輯真的能成立嗎？雖然也明白「這樣想也難怪」，但總是覺得這種說法有些不合適。

　　如果採用「漸進式方法」， XP 就可以應用於大規模開發 !

87

分析：「 XP 」能否進行大規模軟體發展發佈時間： 2001-07-04 15:51:56 來源：日經 BP 社

所謂的大規模軟體發展專案通常指， 1) 開發人員多； 2) 作為開發物件的專案規模大。

大型開發商說的大專案通常都滿足上述 1) 和 2)兩個條件。也就是說投入數百人的開發力量一氣構築起擁有數百萬個開發步驟的軟體。

　　按這個標準看， XP如前所述不能滿足 1) 要求的條件。但能否滿足 2) 的要求呢？

　　 XP 的倡導者 Kent Beck 斷言：「 XP 可以用於大規模的系統開發」。不過， XP 的大規模開發方法與普通的大規模開發專案大不相同。 XP 不是一氣呵成開發出所有的應用，而是採用「漸進式」。

　　所謂的漸進不是從一開始就明確決定應用的具體標準，而是首先做出一個小型的框架，然後在大膽的改進中不斷促進其「成長」。 Beck 將這種開發方法比作園藝。

88

分析：「 XP 」能否進行大規模軟體發展發佈時間： 2001-07-04 15:51:56 來源：日經 BP 社　　「在園藝中，植物要逐年一點點地培育下去。這與軟體的開發也基本相同。

一年年地追加功能是再‘自然’不過的事情了。豈能一下子實現所有的功能、一直用下去！即使勉為其難開發出了這樣的軟體，最後往往也變成了一堆垃圾、被扔到一邊無法使用。而 XP 不僅不排斥變化，而且還歡迎變化，並希望有更多的變化。曾經有過這樣的情況： 3 個人經過 6 年時間的開發，結果形成了可以稱之為大規模系統的軟體。 XP 的一個重要的思想就是‘持續性’」。

　　顯然，那種預先完全確定好系統的功能然後再分為第 1 次開發、第 2 次開發等的階段性實現的做法與 XP 的「漸進式的」方法完全是背道而馳的。

　　實際上，早在 Beck之前就有人表達過類似的看法。此人就是日本物件導向研究開發的先驅 --SRA 的青木淳。他在《物件導向系統分析設計入門》書中說：「大凡軟體發展均應限定於小規模 ( 較少的功能要求和較短的開發期限 ) ，須循序漸進，且忌急於求成」。不得不提到的是， Beck 和青木都是使用 Smalltalk 這一種物件導向語言的著名高手。

　　難道要把反軟體「本質」的開發進行到底嗎？

89

分析：「 XP 」能否進行大規模軟體發展發佈時間： 2001-07-04 15:51:56 來源：日經 BP 社

　　之所以說 XP 採取的是漸進的方法，按純屬軟體工程外行的筆者的理解，是因為 XP 「採用了盡可能忠實於軟體‘本質’的開發方法」。

說到軟體的本質，這是一個非常含糊的概念，但諸如可塑性太大 (簡單地說就是彈性十足 )以及極易受到人這一因素的影響等原因造就了所謂的軟體「特徵」 ( 可能還有其他各種各樣的因素，或許也有筆者理解不對之處，還望讀者諸公多多指教 ) 。

　　不論是要素的定義還是設計，想預先做出全面的規劃，都是不太可能的事情。青木在上述的著作中就列舉出了物件導向軟體發展中的 3 大「前提」：1) 使用者要求的功能永遠不可琢磨； 2) 開發人員設計的功能永遠不能確定；3) 軟體發展永遠不會完成。

　　總而言之， XP 採取漸進的方法就是「因為軟體本來就應該按照其固有的特點來開發」。當然，必須結合當時的情況開發出滿足使用者需求的系統。在不違反軟體本質的前提下，如何才能展開令開發人員和使用者都感到愉快的軟體發展 --從這個角度來看 XP ，就會明白 XP 這種開發方法其實是建立在深思熟慮的基礎上的。

90

eXtreme Programming

謝謝捧場蔡文能

http://tsaiwn.net/course/introcs/