CHAPTER 7 Chapter 7 Software Engineering Glenn Brookshear

CHAPTER 7 Chapter 7 軟體 程 Software Engineering Glenn Brookshear J. J. Glenn 蔡文能

Agenda 7. 1 Software Engineering Discipline? 7. 2 The Software Life Cycle 7. 3 Software Engineering Methodologies 7. 4 Modularity 7. 5 Tools: Dataflow diagram, UML, Design Pattern UML -- Unified Modeling Language 7. 6 Quality Assurance: testing XP : e. Xtreme Programming (1995) 7. 7 Documentation; CMMI by CMU 7. 8 The Human Machine Interface (HMI) 7. 9 Software Ownership and Liability (Intellectual Property) 交大資 蔡文能 計概 2

The Software Life Cycle Development Use Modification Maintenance Waterfall Development phase • Analysis • Design • Implementation • Testing 交大資 蔡文能 計概 model 10

Recent Trends n n n n Incremental model Iterative model • Rational Unified Process (RUP) • • Evolutionary prototyping Throwaway prototyping Prototyping UML – Unified Modeling Language Design Patterns e. Xtreme Programming (1995) Tools: • Structure chart, class diagram, UML, collaboration diagram, dataflow diagram, entity-relationship diagram CRC • (IBM) Rational ROSE for Rational Unified Process • n n (use incremental model) CASE tools (Computer Aided Software Engineering) Unit Test 交大資 蔡文能 計概 11

Software Development 軟體發展 n 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 1. 2. 3. 4. 5. 6. 7. 8. 9. 軟體發展計畫 軟體需求規格 軟體設計規格 資料/程式對照清單 驗收測試計畫 軟體測試報告 軟體使用手冊 系統使用說明會 系統發展過程記錄 MTBF 是用在硬體 交大資 蔡文能 計概 12

Software Engineering “Axioms” (法則) n n Adding developers to a project will likely result in further delays and accumulated costs Basic tension of software engineering • • n The longer a fault exists in software • • n better, cheaper, faster — pick any two! functionality, scalability, performance — pick any two! the more costly it is to detect and correct the less likely it is to be properly corrected Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design • detecting the causes of those faults early may reduce their resulting costs by a factor of 100 or more 交大資 蔡文能 計概 13

就是 要有好的規劃 Plan with SMART Goals n Goals should be SMART • Specific, Strategic ü要明確 -- 到底要做出什麼功能? • Measurable 要可量測 -- 例如可讓 2000人同時選課? • Attainable / Achievable 要可達成 – 合理可行 • Realistic / Relevant ; Result Oriented ü要務實 / 要切題 – 不做沒用的功能 • Time bound 要有時限 -- 三年才做出來那給誰用? Acronym 頭字語 TLA: Three Letter Acronym ROC: Republic Of Confusion 交大資 蔡文能 計概 14

Object Oriented Concepts n n There are many OO tools for Software Engineering (軟體 程 – 計概第七章) OOA (Language Independent) • n Cunningham OOD • n CRC cards (Class-Responsibility-Collaborator) by Ward Class diagram, UML, Rational ROSE, … OOP • Languages support OOP: C++, Java, Ada, … 交大資 蔡文能 計概 15

OOA: CRC Cards n n Step one: Write down all the objects that relate (Focus on the nouns because objects are nouns) Step two: Write CRC cards and work through scenarios • • Class-Responsibility-Collaborator Cards (Cunningham and Beck) Just 3 x 5 cards • Although CRC is not part of UML, they add some very useful insights throughout a development. 交大資 蔡文能 計概 Data fields (attributes) 寫在背面 16

OOD: Object-Oriented Design, How? n n 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 UML == “Unified Modeling Language” 交大資 蔡文能 計概 17

Unified Modeling Language http: //www. omg. org n n http: //www. UML. org 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) (Object Constrain Language) amigos = friends 交大資 蔡文能 計概 18

So, What is UML? n n n 軟體 程師共通的語言 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 ML is a “blueprint” for building complex softw 交大資 蔡文能 計概 19

History of the UML( http: //www. uml. org/ ) Public Feedback Approved 2004 UML 2. 0 Minor revision 2003 UML 1. 5 Minor revision 2001 UML 1. 4 Minor revision 1999 UML 1. 3 OMG Acceptance, Nov 1997 Final submission to OMG, Sept 1997 First submission to OMG, Jan 1997 UML 1. 1 UML partners UML 1. 0 Web - June 1996 UML 0. 9 OOPSLA 95 Other 交大資 蔡文能 計概 Unified Method 0. 8 methods OOSE Booch method OMT 20

UML 常用的 Diagrams n Use case diagrams • n Class diagrams • n Dynamic behavior of a system, in particular the workflow, i. e. a flowchart. Sequence diagrams • n Static structure of the system: Objects, Attributes, and Associations. Activity diagrams • n Functional behavior of the system as seen by the user. Dynamic behavior between actors and system objects. Statechart diagrams • Dynamic behavior of an individual object as FSM (有限狀態機). 交大資 蔡文能 計概 21

UML 12 Diagrams n Behavior : • • • n Use Case Sequence Collaboration State Chart Activity n Structural: • • Class Component Deployment Object Model Management: • • • Packages (class diagram contains packages) Subsystems (class diagram contains subsystems) Models (class diagram contains models) 交大資 蔡文能 計概 22

UML Core Conventions n n n Rectangles are classes or instances Ovals are functions or use cases Types are denoted with non-underlined names ü ü n Instances are denoted with an underlined names ü ü n Simple. Watch Firefighter my. Watch: Simple. Watch Joe: Firefighter Diagrams are higraphs • • • 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. ). 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) 交大資 蔡文能 計概 23

Use Case Diagram examples Package Simple. Watch Actor Read. Time Watch. User Use case 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. Set. Time Watch. Repair. Person Change. Battery Use case diagrams represent the functionality of the system from user’s point of view. (強調 what, 但暫不管 how) 交大資 蔡文能 計概 24

Class Diagram : a simple Watch Class Multiplicity 1 2 Push. Button state push() release() Attributes Association Simple. Watch 1 LCDDisplay blink. Idx blink. Seconds() blink. Minutes() blink. Hours() stop. Blinking() referesh() 1 1 1 2 Battery load() 1 Time now() Operations Class diagrams represent the structure of the domain or system 交大資 蔡文能 計概 25

Object : Watch. User Sequence Diagram : Simple. Watch press. Button 1() : LCDDisplay : Time blink. Hours() blink. Minutes() press. Button 2() increment. Minutes() refresh() press. Buttons 1 And 2() Activation commit. New. Time() stop. Blinking() Activation Message Sequence diagrams represent the behavior as interactions It shows sequence of events for a particular use case Object diagram with numbered messages Sequence numbers of messages are nested by procedure call Collaboration Diagram 交大資 蔡文能 計概 26

State chart Diagrams for the watch Event Initial state button 1&2 Pressed Increment Hours button 1 Pressed Transition button 1&2 Pressed button 2 Pressed Blink Hours State Blink Minutes button 2 Pressed Increment Minutes button 1 Pressed button 1&2 Pressed Stop Blinking Blink Seconds Final state 交大資 蔡文能 計概 button 2 Pressed Increment Seconds FSM: Finite State Machine 27

Activity Diagrams n An activity diagram shows flow control within a system n An activity diagram is a special case of a state chart diagram in which states are activities (“functions”) Two types of states: n • Action state: Cannot be decomposed any further Happens “instantaneously” with respect to the level of abstraction used in the model • Activity state: Can be decomposed further The activity is modeled by another activity diagram 描述Business process或use case的操作流程; 像流程圖 交大資 蔡文能 計概 28

Classes in UML n Classes describe objects • • • n 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 交大資 蔡文能 計概 29

Visibility shown as + public private # protected UML Class name Data members (attributes) Instance methods Class method (static) Arguments Return types Data members, arguments and methods are specified by visibility name : type 交大資 蔡文能 計概 30

Class Attributes are the instance data members and class data members Class name Class data members (underlined) are shared between all instances (objects) of a given class Attribute compartment Data types shown after ": " Visibility shown as + public private # protected 交大資 蔡文能 計概 visibility name : type + - 31

Class Operations (Interface) Operations are the class methods with their argument and return types Public (+) operations define the class interface Class methods (underlined) can only access to class data members, no need for a class instance (object) 交大資 蔡文能 計概 Operations compartment 32

Template (樣板) Classes Type parameter(s) Operations compartment as usual, but may have type parameter instead of concrete type Generic classes depending on parametrised types 交大資 蔡文能 計概 33

Class Inheritance (繼承; 擴充) Base class or super class Arrow shows direction of dependency (B inherits A) Derived class or subclass → → → 交大資 蔡文能 計概 B inherits A's interface, behaviour and data members B can extend A, i. e. add new data members or member functions B depends on A, A knows nothing about B 34

Recommended Book: UML Distilled n n n Serious O-O designers DO use UML Distilled by Martin Fowler is a great practical introduction to UML Official UML book series published by Addison-Wesley http: //www. omg. org 交大資 蔡文能 計概 35

A structure chart showing data coupling 交大資 蔡文能 計概 36

Logical and functional cohesion within an object representing an order form in a simple Internet “mail order” business 交大資 蔡文能 計概 37

A dataflow diagram of a simple Internet “mail order” business 交大資 蔡文能 計概 38

An entity-relationship diagram One-to-one, one-to-many, and many-to-many relationships between entities of types X and Y 交大資 蔡文能 計概 39

Design Patterns n n n A design pattern captures design expertise – patterns are not created from thin air, but abstracted from existing design examples Each pattern describes a problem which occurs over and over again in our environment Using design patterns is reuse of design expertise Studying design patterns is a way of studying how the “experts” do design Design patterns provide a vocabulary for talking about design 交大資 蔡文能 計概 40

Why design patterns? n n If you’re a software engineer, you should know about them anyway There are many architectural patterns published, and the Go. F Design Patterns is a prerequisite to understanding these: • • n Mowbray and Malveau – CORBA Design Patterns Schmidt et al – Pattern-Oriented Software Architecture Design Patterns help you break out of first -generation OO thought patterns 交大資 蔡文能 計概 41

Structure of a pattern n n n n Name Intent Motivation Applicability Structure Consequences Implementation Known Uses Related Patterns 交大資 蔡文能 計概 42

Patterns vs. “Design” n Patterns are design • • But: patterns transcend the “identify classes and associations” approach to design Instead: learn to recognize patterns in the problem space and translate to the solution Patterns can capture OO design principles within a specific domain n Patterns provide structure to “design” n 交大資 蔡文能 計概 43

Patterns vs. Frameworks n n Patterns are lower-level than frameworks Frameworks typically employ many patterns: • • n Factory Strategy Composite Observer Done well, patterns are the “plumbing” of a framework Framework 就是做了一半的Application 交大資 蔡文能 計概 44

Patterns vs. Architecture n n Design Patterns (Go. F) represent a lower level of system structure than “architecture” (cf: seven levels of A) Patterns can be applied to architecture: • • • n Mowbray and Malveau Buschmann et al Schmidt et al Architectural patterns tend to be focussed on middleware. They are good at capturing: • • • Concurrency Distribution Synchronization 交大資 蔡文能 計概 45

N tier Architecture n The n tier architecture is based on the concept of separating a system to different layers (usually 3) Each layer interacts with only the layer directly below, and has specific function that it is responsible for. n Classic for IT systems 3 -Tier if N == 3 交大資 蔡文能 計概 46

MDA-Model Driven Architecture? n A New Way to Specify and Build Systems • • • 2001年由OMG制定的新開發架構 (http: //www. omg. org) 以 UML Model(塑模)為基礎 支援完整開發週期: Analysis, Design, Implementation, Deployment, Maintenance, Evolution & Integration with later systems (改進與後續整合) 內建協同運作性及跨平台性 降低開發初期成本及提高ROI (投資報酬) 可套用至你所使用的任何環境: Programming language Network Operating System Middleware 交大資 蔡文能 計概 47

SOA : Service Oriented Architecture n n n SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer in SOA, services are the mechanism by which needs and capabilities are brought together. 交大資 蔡文能 計概 48

List of Design Patterns n Creational Patterns • Abstract Factory • Builder • Factory Method • Prototype • Singleton n Behavioral Patterns • Chain of Responsibility • Command • Interpreter • Iterator • Mediator 交大資 蔡文能 計概 n • • • Structural Patterns • Adapter • Bridge • Composite • Decorator • Facade • Flyweight • Proxy Memento Observer State Strategy Template Method Visitor 49

Factory design patterns (abstractmethodLightweight ) n n n Creational pattern Can be given to client (abstract), pass construction parameters or read creation types from configuration or system environment Can use object pool (Lightweight) 定義一個抽象類別，由其他類別繼承它 交大資 蔡文能 計概 50

Composite design patterns n n n Construct part-whole hierarchy Simplify client interface to leaves/composites Easier to add new kinds of components Client Component 0. . * Operation() Add(Component) Remove(Component) children 交大資 蔡文能 計概 Leaf Composite Operation() Add(Component) Remove(Component) For all c in children c. Operation(); 51

Observer design patterns n Behavioral Pattern n one-to-many dependency model, so that when one object changes state, all its dependents are notified and updated automatically without coupling the notifying object to the objects that are notified. (一對多的物件依存關係) Example: n Button expose a clicked event that encapsulate click state, thus publish himself as an observable. Clients that are interested in this event register to it, thus becomes observers. n Observer and observable are bonded in a contract and can be completely loosely coupled from one another. 交大資 蔡文能 計概 52

Strategy design patterns n n n Behavioral Pattern Make algorithms interchangeable---”changing the guts” Alternative to subclassing Choice of implementation at run-time Increases run-time complexity ! 定義一整套演算法，將每一個演算法封裝起來，可動態互換使用。 Strategy Context. Interface() Operation() Concrete. Strategy 1 Operation() 交大資 蔡文能 計概 Concrete. Strategy 2 Operation() 53

Decorator design pattern n Structural Pattern Avoid excessive sub-classing and gain run time flexibility n Example: Java. IO package n Buffered. Reader br = new Buffered. Reader( new Input. Stream. Reader( new File. Input. Stream(in. File))); All derives from abstract io. Reader 交大資 蔡文能 計概 54

MVC Design Patterns (1/2) View character-based View GUI, Document 1 n GUI, Document 2 Model • • n Controller Model EUR -> US $ Implements algorithms (business logic) Independent of environment View: • • • n Model US $ -> EUR Communicates with environment Implements I/O interface for model Listens to Model Changed events and update itself Controller: • Controls data exchange (notification protocol) between model and view 交大資 蔡文能 計概 55

MVC Design Patterns (2/2) n MVC decouples views from models – more general: • • • n MVC allows view to be nested: • • n Composite. View objects act just as View objects Composite pattern describes the more general problem of grouping primitive and composite objects into new objects with identical interfaces MVC controls appearance of view by controller: • n Decoupling objects so that changes to one can affect any number of others without requiring the object to know details of the others Observer pattern solves the more general problem Example of the more general Strategy pattern MVC uses Factory and Decorator patterns as well 交大資 蔡文能 計概 56

Façade Design Pattern n Structural Pattern n Façade: defines a clean, high-level interface to a subsystem. Context: building easy-to-use and maintain subsystems Problem: Each class in the subsystem provides part of the subsystem’s functionality, clients has to know the inside, changes to the subsystem may require changes to the clients. Solution: Add an interface class (the façade class) that knows the structure of the subsystem and forwards requests… Consequences: no or less dependency of client from structure of subsystem, ideal for layered subsystems n n Facade 交大資 蔡文能 計概 57

Testing Stubs & Testing Driver n n Testing Stubs: If the function A you are testing calls another function B, then use a simplified version of function B, called a stub. (虛構的function) Testing driver – allows you to call a function and display its return values. (可以測試你的function，並驗證回傳結果) your. Function Testing Driver int main() { int your. Function( ){ //呼叫其他程式 … //呼叫被測試程式 … } 交大資 蔡文能 計概 int other. Function( ) { return 1; } other. Function your. Function //驗證結果 … Testing Stub … } 58 58

Unit Testing (Component Testing) n Testing individual subsystems (collection of classes) System Design Document Subsystem Code n Unit Test Goal: Confirm that subsystem is correctly coded and carries out the intended functionality 59 交大資 蔡文能 計概 59

Unit Testing 1. 寫好一個物件的功 能 2. 決定測試資料 3. 開始測試 交大資 蔡文能 計概 /* 帳號的長度限定為 3 到 8 個字元*/ class system{ bool validate. User. ID(const char* user. ID){ int num = strlen(user. ID); return (num >= 3 )&& (num <= 7 ); } } Test Case Validate user. ID Return 測試結果 確認 a False ○ Cat True ○ Bush True ○ abcdekkk True False × Washington False ○ 測試結果第四項目不符合表示程式有錯 6060

Integration Testing groups of subsystems and eventually the entire system Subsystem Code System Design Document Integration Test Subsystem Code n Goal: Test interfaces between subsystems 交大資 蔡文能 計概 61 61

References about Patterns n n Pattern FAQ http: //g. oswego. edu/dl/pd-FAQ. html Basic patterns http: //exciton. cs. oberlin. edu/javaresources/De sign. Patterns/default. htm Patterns home page http: //hillside. net/patterns/ Gamma, Helm, Johnson, and Vlissides (the “Gang of Four”) – Design Patterns, Elements of Reusable Object-Oriented Software 交大資 蔡文能 計概 62

Prototyping(系統雛形法) n n n Prototyping is the rapid development of a system In the past, the developed system was normally thought of as inferior in some way to the required system so further development was required Now, the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach 交大資 蔡文能 計概 63

Uses of system prototypes n The principal use is to help customers and developers understand the requirements for the system • • n Requirements elicitation. Users can experiment with a prototype to see how the system supports their work Requirements validation. The prototype can reveal errors and omissions in the requirements Prototyping can be considered as a risk reduction activity which reduces requirements risks 交大資 蔡文能 計概 64

Prototyping benefits n n n Misunderstandings between software users and developers are exposed Missing services may be detected and confusing services may be identified A working system is available early in the process The prototype may serve as a basis for deriving a system specification The system can support user training and system testing 交大資 蔡文能 計概 65

Prototyping process 交大資 蔡文能 計概 66

Prototyping benefits n n n Improved system usability Closer match to the system needed Improved design quality Improved maintainability Reduced overall development effort 交大資 蔡文能 計概 67

Prototyping in the software process n Evolutionary prototyping • n An approach to system development where an initial prototype is produced and refined through a number of stages to the final system Throw-away prototyping • A prototype which is usually a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process 交大資 蔡文能 計概 68

Prototyping objectives n n The objective of evolutionary prototyping is to deliver a working system to end-users. The development starts with those requirements which are best understood. The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood 交大資 蔡文能 計概 69

Approaches to prototyping 交大資 蔡文能 計概 70

Evolutionary prototyping n n n Must be used for systems where the specification cannot be developed in advance e. g. AI systems and user interface systems Based on techniques which allow rapid system iterations Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system 交大資 蔡文能 計概 71

Evolutionary prototyping 交大資 蔡文能 計概 72

Evolutionary prototyping advantages n Accelerated delivery of the system • n Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability User engagement with the system • Not only is the system more likely to meet user requirements, they are more likely to commit to the use of the system 交大資 蔡文能 計概 73

Evolutionary prototyping n n Specification, design and implementation are inter-twined The system is developed as a series of increments that are delivered to the customer Techniques for rapid system development are used such as CASE tools and 4 GLs User interfaces are usually developed using a GUI development toolkit 交大資 蔡文能 計概 74

Evolutionary prototyping problems n Management problems • • n Maintenance problems • n Existing management processes assume a waterfall model of development Specialist skills are required which may not be available in all development teams Continual change tends to corrupt system structure so long-term maintenance is expensive Contractual problems 交大資 蔡文能 計概 75

Prototypes as specifications n n n Some parts of the requirements (e. g. safety-critical functions) may be impossible to prototype and so don’t appear in the specification An implementation has no legal standing as a contract Non-functional requirements cannot be adequately tested in a system prototype 交大資 蔡文能 計概 76

Incremental development n n System is developed and delivered in increments after establishing an overall architecture Requirements and specifications for each increment may be developed Users may experiment with delivered increments while others are being developed. therefore, these serve as a form of prototype system Intended to combine some of the advantages of prototyping but with a more manageable process and better system structure 交大資 蔡文能 計概 77

Incremental development process 交大資 蔡文能 計概 78

Throw-away prototyping n n n Used to reduce requirements risk The prototype is developed from an initial specification, delivered for experiment then discarded The throw-away prototype should NOT be considered as a final system • • • Some system characteristics may have been left out There is no specification for long-term maintenance The system will be poorly structured and difficult to maintain 交大資 蔡文能 計概 79

Throw-away prototyping 交大資 蔡文能 計概 80

Prototype delivery n n Developers may be pressurised to deliver a throwaway prototype as a final system This is not recommended • • It may be impossible to tune the prototype to meet nonfunctional requirements The prototype is inevitably undocumented The system structure will be degraded through changes made during development Normal organisational quality standards may not have been applied 交大資 蔡文能 計概 81

Rapid prototyping techniques n Various techniques may be used for rapid development • • • n n Dynamic high-level language development Database programming Component and application assembly These are not exclusive techniques - they are often used together Visual programming is an inherent part of most prototype development systems 交大資 蔡文能 計概 82

CMMI Overview n 軟體開發能力評鑑 n Capability Maturity Model (能力成熟度模型) n CMM與CMMI的一些差異 CMMI是壓垮軟體 業的最後一根稻草嗎? CMMI沒有人性，雞排 程師的哀歌 n n n Process is the focus n 5 Maturity Levels 交大資 蔡文能 計概 83

5 Maturity Levels in CMMI 1. 2. 3. 4. 5. Initial Managed Defined Quantitatively Managed Optimizing 交大資 蔡文能 計概 85

Process Improvement Focus 交大資 蔡文能 計概 86

CMMI Reference n Version Control & Process tracker tool 3. IBM Rational Clear. Case Merant PVCS VM & Tracker Open Source Subversion、CVS SVK…. . n Ref. Link 1. 2. uhttp: //www. sei. cmu. edu/cmmi/ uhttp: //www. csqa. org. tw/portal /modules/news/ n CMMI QBQ 交大資 蔡文能 計概 92

Introduction to e. Xtreme Programming Yet-Shiang Wang, Wen-Nung Tsai wangys@csie. nctu. edu. tw (汪益賢) tsaiwn@csie. nctu. edu. tw (蔡文能) Department of Computer Science and Information Engineering National Chiao Tung University 93

Outline What is XP(e. Xtreme Programming) ? n Four variables of software development n e. Xtreme Programming(XP) n A development episode n The basic practices of XP n 交大資 蔡文能 計概 94

Four variables of software development (1/2) 1. 2. 3. 4. Cost Time Quality 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. 交大資 蔡文能 計概 96

Four variables of software development (2/2) n 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! 交大資 蔡文能 計概 97

Analysis of the four variables (1/4) n Cost: • • n 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 Y 2 K, the end of the year, and so on. Nine women cannot make a baby in one month! 交大資 蔡文能 計概 98

Analysis of the four variables (2/4) n 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. 交大資 蔡文能 計概 99

Analysis of the four variables (3/4) n 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). 交大資 蔡文能 計概 100

Analysis of the four variables (4/4) n 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)軟體發展永遠不會完成。 交大資 蔡文能 計概 101

Costs of change (1 /4) n One of the universal assumptions of software engineering is that the cost of change rises exponentially over time. 交大資 蔡文能 計概 102

Costs of change (2/4) n 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. 交大資 蔡文能 計概 103

Costs of change (3/4) n If the cost of change rises slowly as asymptote over time, what development strategy will you take? 交大資 蔡文能 計概 104

Costs of change (4/4) n Why can we achieve this goal? • • n 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! 交大資 蔡文能 計概 105

e. Xtreme Programming (1/2) n What is e. Xtreme 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 wellknown 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. 交大資 蔡文能 計概 106

e. Xtreme Programming (2/2) n 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. 交大資 蔡文能 計概 107

The basic practices of XP The 12 core practices of XP are: n 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. n The planning game Small releases System metaphor On-site customer. S Pair programming Simple design Continuous testing Coding standards Collective code ownership Refactoring Continuous integration 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. 交大資 蔡文能 計概 108

A development episode Boss Customer The 8 -player Army Chess Game Development team 交大資 蔡文能 計概 109

1. The planning game (1/6) n Business and development cooperate to produce the maximum business value as rapidly as possible. 1. 2. 3. 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. Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration). 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. 交大資 蔡文能 計概 113

1. The planning game (2/6) n n 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 Load. Factor (see Project. Velocity) of 3 real weeks per ideal week to convert the final schedule to real time. 交大資 蔡文能 計概 114

1. The planning game (3/6) n n n 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. 交大資 蔡文能 計概 115

1. The planning game (4/6) n 1. 2. 3. Value and Risk First: Development orders the Stories in a commitment so: A fully working but sketchy system is completed immediately (like in a couple of weeks) More valuable Stories are moved earlier in the schedule (Business. Value. First) Riskier Stories are moved earlier in the schedule (Worst. Things. First) 交大資 蔡文能 計概 116

1. The planning game (5/6) n n n Overcommitment Recovery: Development had predicted they could do 150 units of stories between now and the deadline. Based on measuring Project. Velocity, 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. 交大資 蔡文能 計概 117

1. The planning game (6/6) n n n 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 User. Story to account for it. That Story is scheduled according to Value And Risk First. Regular spikes, especially fire-fighting ones, will affect the Load. Factor. Re-estimate: Development estimates the remaining stories in the Commitment again. This can spark an Overcommitment. Recovery. 交大資 蔡文能 計概 118

2. Small releases, Frequent Releases n n n Start with the smallest useful feature set. Release early and often, adding a few feature each time. Small. Releases 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 User. Stories each cycle). n n 交大資 蔡文能 計概 小量發行(Small Releases) 頻繁的發行(Frequent Releases) 120

3. System metaphor n n n 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? 交大資 蔡文能 計概 121

4. On-site customer n n n 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. 交大資 蔡文能 計概 122

5. Pair programming (1/3) n n n 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 Unit. Tests the other thinks about the class that will satisfy the test, for example. 在理想的XP專案當中，開發者是成對的 作，而且也 不是靜態的成對：依據哪些事要做而誰知道怎麼做， 人們可能變換伙伴一天好幾次。這個想法；當然是立 基於格言「兩個頭腦比一個好(two heads are better than one)」。 交大資 蔡文能 計概 124

5. Pair programming (2/3) n n n 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. 交大資 蔡文能 計概 125

5. Pair programming (3/3) n n n One programmer designs, the other one does the programming. Both programmers can get control of the keyboard and mouse. Pair programming can • • n 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%. 交大資 蔡文能 計概 129

Costs of pair programming n 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. 交大資 蔡文能 計概 130

Benefits of pair programming (1/2) n The resulting code has about 15% fewer defects. 交大資 蔡文能 計概 131

Benefits of pair programming (2/2) n The pairs implemented the same functionality as the individuals in fewer lines of code. 交大資 蔡文能 計概 132

6. Simple design n n 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 Business. Value is wasteful. KISS = Keep It Simple and Stupid 交大資 蔡文能 計概 135

7. Continuous testing 1. 2. Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors. • • 3. 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. When all the functional tests pass for a given user story, that story is considered complete. n Ideally functional tests should be automated 交大資 蔡文能 計概 137

Coding Standard and Convention Discipline (紀律) 8. Coding standards n n n 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 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. 交大資 蔡文能 計概 139

9. Collective code ownership n n n 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 Coding. Standards; code management tools to detect and resolve conflicts (CVS!); a comprehensive suite of Unit. Tests to ensure quality; powerful browsing and Refactoring. Tools to find references to old methods and replace them with the new; Continuous. Integration (or nearly that) so that conflicts are rare (also CVS). 交大資 蔡文能 計概 142

10. Refactoring n n n 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. 交大資 蔡文能 計概 143

11. Continuous Integration n 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 交大資 蔡文能 計概 145

Do you live to work? or do you work to live? 12. Forty-hour work week n n n Over. Time 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. 交大資 蔡文能 計概 146

147

References n n Kent Beck, "Extreme Programming Explained, " Addison-Wesley Pub Co; 1 st 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 交大資 蔡文能 計概 148

Software Engineering e. Xtreme Programming 謝謝捧場 蔡文能 The Software Engineering Discipline 交大資 蔡文能 計概 153