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

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 : eXtreme Programming (1995) 7.7 Documentation; CMMI by CMU 7.8 The Human Machine Interface (HMI) 7.9 Software Ownership and Liability (Intellectual Property)

What is Software Engineering (何謂 軟體工程 ?) 1968年秋季，NATO（北約組織）的科技委員會召集了近50名一流的程式設計人員、電腦科學家和工業界巨頭，討論和制定擺脫「軟體危機」的對策。在那次會議上第一次提出了軟體工程（software engineering）這個概念。 軟體工程是一種用於指導電腦軟體發展和維護的工程學科。 採用工程的概念、原理、技術和方法來開發與維護軟體，應用正確的管理技術與紀律，結合當前最好的技術，使得軟體的發展和維護更有效率，這就是軟體工程。 (其實就是研如何充分壓榨程式人員!)

「八二」法則 -- by 社會學家柏雷多(Pareto) 什麼是八二法則？ Why Software Engineering? (1/2) 「八二」法則 -- by 社會學家柏雷多(Pareto) 80% vs. 20% (or 90% vs. 10%) 義大利經濟學家 Vilfredo Pareto(柏雷多)發現八二法則，他確認義大利國家 80%的土地(財富)由 20%的人口所擁有 ! 國家80% 的人口被20%的人統治 。 80% 的人輸給20%的人 ( 賭博) 。 股市中只有二成的人是賺錢的，其餘八成 的人是賠錢的 。 企業80%的利潤來自20%的客戶! (其他客戶是澳洲來的?) 80%的時間花在解決20%的問題 。 (80% in Debugging?) 效率! 效率 !! 效率 !!!

Why Software Engineering? (2/2) 「艾森豪」法則 美國艾森豪將軍指出，人們的精力，往往被緊急但較不重要的事情所佔用，而並未完全或儘可能的將時間與精力用在重要的事。 「艾森豪」法則的啟示：留多一點時間給重要的事情。 But How ? 沒時間我沒時間一瞬間來到夏天單身的地平線又轉了一圈晴天終於出現轉變 .. 其實只要20%的時間就可以完成80%的事情

「艾森豪」法則規劃矩陣 時間管理矩陣 一般錯誤時間配置 重要性 緊急度 緊急的事 不緊急的事 重要的事 1 st 重要且緊急 Do it now 2 nd 重要但不急 Defer  Plan 不重要的事 3 rd 很急但不重要 Delegate 4 th 不重要也不急 Dump it 25% 30% 重要性 30% 15% 緊急度

六二二彈性原則

正確的行事優先順序與時間分配 時間管理矩陣 重 留多一點時間給重要的事情 35% 50% 12% 3% 緊急的事 不緊急的事 重要的事 1 st 急 2 nd 重 不重要的事 3 rd 輕 4 th 緩 35% 50% 12% 3% 時間管理矩陣

 剩下的時間優先分配於有興趣的或效用大的 ! 我是學生, 八二法則干我屁事 各科前面的80分通常只要花20%的努力 努力成果邊際效用遞減 沒有人要你每科拿 100 分 程式(習題)20%的時間可以完成80% 儘快完成最關鍵的部份，讓事情看起來像做完 80% 一般。  每科都先拿80分再說 ! (20%的力氣)  剩下的時間優先分配於有興趣的或效用大的 !

The Software Life Cycle Development  Use  Modification Development phase Analysis Design Implementation Testing Maintenance Waterfall model

Recent Trends Incremental model Iterative model Rational Unified Process (RUP) Prototyping Evolutionary prototyping (use incremental model) Throwaway prototyping UML – Unified Modeling Language Design Patterns eXtreme Programming (1995) Tools: Structure chart, class diagram, UML, collaboration diagram, dataflow diagram, entity-relationship diagram CRC CASE tools (Computer Aided Software Engineering) (IBM) Rational ROSE for Rational Unified Process Unit Test

Software Development 軟體發展 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 軟體發展計畫 軟體需求規格 軟體設計規格 資料/程式對照清單 驗收測試計畫 軟體測試報告 軟體使用手冊 系統使用說明會 系統發展過程記錄 MTBF 是用在硬體

Software Engineering “Axioms” (法則) Adding developers to a project will likely result in further delays and accumulated costs Basic tension of software engineering better, cheaper, faster — pick any two! functionality, scalability, performance — pick any two! The longer a fault exists in software 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

Plan with SMART Goals 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

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

OOA: CRC Cards 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 3x5 cards Although CRC is not part of UML, they add some very useful insights throughout a development. Data fields (attributes) 寫在背面

OOD: Object-Oriented Design, How? 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”

Unified Modeling Language http://www.omg.org 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

UML is a “blueprint” for building complex software 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

History of the UML( http://www.uml.org/ ) Approved 2004 Public Feedback Minor revision 2003 UML 1.5 UML 1.4 Minor revision 2001 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 1.0 UML partners You have to have a common language to unify your developers. UML 1.3 is the current revision. UML 1.4 was just approved by the Revision Task Force (2/2/01). UML 1.4 is not released yet, but expect it to be soon. [speaker: use as much of this history as you feel the audience needs/wants.] The UML was created by bringing together the best parts of the industry leading methodologies. In fact it was created at Rational by Grady Booch, Ivar Jacobson, and James Rumbaugh. In the late 80s and early 90s there were many different methodologies. Three of the more popular methods were the Booch method by Grady Booch, the OMT method by Jim Rumbaugh, and the OOSE method by Ivar Jacobson. They started to merge over time. At OOPSLA in 1995, the .8 version of the Unified Method was published. It was at this time that Objectory joined the Rational family. Ivar was then included in the unification process and the 3 amigos were born. The 3 amigos spent until June 1996 maturing the Unified Method. In June, the .9 version was published and public feedback was collected. It was also during this time that feedback was incorporated from our UML partners -- “little” companies like Microsoft, Oracle, IBM to name a few. In January 1997, the 1.0 version was released. Final feedback was collected and incorporated into the UML 1.1 version. CLICK: Current minor revision is UML 1.3 It continues to be extended and refined by soliciting industry feedback and including the best constructs from other methods and languages. An example of this is the inclusion of the real-time profile (by Selic and Gullekson) in UML 1.4. CLICK: Here is a look at the plan for future revisions. Major Point : Just as hardware engineers have electrical schematics, UML is the standard design language for software development. [Speaker : The Revision Task Force of OMG has recommended the following areas be considered for UML 2.0: Definition of a physical metamodel architecture, Improve the enhanceability mechanism, Improve semantics and notation for components, Definition of activity graph semantics independent of statechart semantics, Improved support for enterprise architecture views, among others. At this time, UML 1.4 is planned to be a minor technical revision containing just those items that could not be completed in UML 1.3] Web - June 1996 UML 0.9 OOSE Other methods Unified Method 0.8 OOPSLA 95 OMT Booch method

UML 常用的 Diagrams Use case diagrams Class diagrams Activity 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 Structural: Behavior : Class Component Deployment 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)

UML Core Conventions 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.). 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) 21

Use Case Diagram examples Package 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. Actor SimpleWatch ReadTime SetTime WatchUser WatchRepairPerson Use case ChangeBattery Use case diagrams represent the functionality of the system from user’s point of view. (強調 what, 但暫不管 how) 16

Class Diagram : a simple Watch Multiplicity Association SimpleWatch 1 1 1 1 2 1 2 1 PushButton state push() release() LCDDisplay Battery load() Time now() blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() Attributes Operations Class diagrams represent the structure of the domain or system 17

Sequence Diagram Object diagram with numbered messages Activation Sequence diagrams represent the behavior as interactions It shows sequence of events for a particular use case blinkHours() blinkMinutes() incrementMinutes() refresh() commitNewTime() stopBlinking() pressButton1() pressButton2() pressButtons1And2() :WatchUser :Time :LCDDisplay :SimpleWatch Object diagram with numbered messages Sequence numbers of messages are nested by procedure call Collaboration Diagram 18

State chart Diagrams for the watch Event Initial state button1&2Pressed button1Pressed button2Pressed Increment Minutes Hours Blink Seconds Stop Blinking State Transition button1&2Pressed Final state FSM: Finite State Machine 19

描述Business process或use case的操作流程; 像流程圖 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 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的操作流程; 像流程圖

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

Data members, arguments and methods are specified by Visibility shown as + public - private # protected UML Class Class name Data members (attributes) Instance methods Class method (static) Return types Arguments Data members, arguments and methods are specified by visibility name : type

Class Attributes + - Attributes are the instance data members and 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 Attribute compartment Class name visibility name : type + -

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

Generic classes depending on parametrised types Template (樣板) Classes Type parameter(s) Operations compartment as usual, but may have type parameter instead of concrete type Generic classes depending on parametrised types

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

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

A structure chart showing data coupling

Logical and functional cohesion within an object representing an order form in a simple Internet “mail order” business

A dataflow diagram of a simple Internet “mail order” business

An entity-relationship diagram One-to-one, one-to-many, and many-to-many relationships between entities of types X and Y

Design Patterns 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

Why design patterns? If you’re a software engineer, you should know about them anyway There are many architectural patterns published, and the GoF Design Patterns is a prerequisite to understanding these: 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

Structure of a pattern Name Intent Motivation Applicability Structure Consequences Implementation Known Uses Related Patterns

Patterns vs. “Design” 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 Patterns provide structure to “design”

Patterns vs. Frameworks Patterns are lower-level than frameworks Frameworks typically employ many patterns: Factory Strategy Composite Observer Done well, patterns are the “plumbing” of a framework Framework 就是做了一半的Application

Patterns vs. Architecture Design Patterns (GoF) represent a lower level of system structure than “architecture” (cf: seven levels of A) Patterns can be applied to architecture: 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

N tier Architecture 3-Tier if N == 3 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. Classic for IT systems 3-Tier if N == 3

MDA-Model Driven Architecture? 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

SOA : Service Oriented Architecture 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.

List of Design Patterns Creational Patterns Abstract Factory Builder Factory Method Prototype Singleton Structural Patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy Behavioral Patterns Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

Factory design patterns (abstract\method\Lightweight) 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) 定義一個抽象類別，由其他類別繼承它

Composite design patterns Construct part-whole hierarchy Simplify client interface to leaves/composites Easier to add new kinds of components For all c in children c.Operation(); Component Operation() Add(Component) Remove(Component) Composite Leaf Client children 0..*

Observer design patterns Behavioral Pattern 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: 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. Observer and observable are bonded in a contract and can be completely loosely coupled from one another.

Strategy design patterns Behavioral Pattern Make algorithms interchangeable---”changing the guts” Alternative to subclassing Choice of implementation at run-time Increases run-time complexity ! 定義一整套演算法，將每一個演算法封裝起來，可動態互換使用。 Strategy Operation() ConcreteStrategy2 Context ContextInterface() ConcreteStrategy1

Decorator design pattern Structural Pattern Avoid excessive sub-classing and gain run time flexibility Example: Java.IO package BufferedReader br = new BufferedReader( new InputStreamReader(            new FileInputStream(inFile))); All derives from abstract io.Reader

MVC Design Patterns (1/2) View character-based Controller Model US $ -> EUR View GUI, Document 1 View GUI, Document 2 Model EUR -> US $ Model Implements algorithms (business logic) Independent of environment View: 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

MVC Design Patterns (2/2) MVC decouples views from models – more general: 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 MVC allows view to be nested: CompositeView 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: Example of the more general Strategy pattern MVC uses Factory and Decorator patterns as well

Façade Design Pattern Facade Structural Pattern 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 Facade

Testing Stubs & Testing Driver 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，並驗證回傳結果) int main() { //呼叫被測試程式 … //驗證結果 } Testing Driver yourFunction yourFunction int otherFunction( ) { return 1; } Testing Stub int yourFunction( ){ //呼叫其他程式 … } otherFunction 58

Unit Testing (Component Testing) Testing individual subsystems (collection of classes) Goal: Confirm that subsystem is correctly coded and carries out the intended functionality System Design Document Subsystem Code Unit Test 59

Unit Testing 寫好一個物件的功能 決定測試資料 開始測試 /* 帳號的長度限定為 3 到 8 個字元*/ /* 帳號的長度限定為 3 到 8 個字元*/ class system{ bool validateUserID(const char* userID){ int num = strlen(userID); return (num >= 3 )&& (num <= 7 ); } Test Case Validate userID Return 測試結果 確認 a False ○ Cat True Bush abcdekkk × Washington 去DB比對 寫基本資料 測試結果第四項目不符合表示程式有錯 60 60

Integration Testing Testing groups of subsystems and eventually the entire system Goal: Test interfaces between subsystems System Design Document Subsystem Code Subsystem Code Integration Test Subsystem Code 61

References about Patterns Pattern FAQ http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html Basic patterns http://exciton.cs.oberlin.edu/javaresources/DesignPatterns/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

Prototyping(系統雛形法) 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

Uses of system prototypes The principal use is to help customers and developers understand the requirements for the system 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

Prototyping benefits 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

Prototyping process

Prototyping benefits Improved system usability Closer match to the system needed Improved design quality Improved maintainability Reduced overall development effort

Prototyping in the software process Evolutionary prototyping 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

Prototyping objectives 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

Approaches to prototyping

Evolutionary prototyping 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

Evolutionary prototyping

Evolutionary prototyping advantages Accelerated delivery of the system 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

Evolutionary prototyping 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 4GLs User interfaces are usually developed using a GUI development toolkit

Evolutionary prototyping problems Management problems Existing management processes assume a waterfall model of development Specialist skills are required which may not be available in all development teams Maintenance problems Continual change tends to corrupt system structure so long-term maintenance is expensive Contractual problems

Prototypes as specifications 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

Incremental development 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

Incremental development process

Throw-away prototyping 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

Throw-away prototyping

Prototype delivery Developers may be pressurised to deliver a throw-away prototype as a final system This is not recommended It may be impossible to tune the prototype to meet non-functional 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

Rapid prototyping techniques Various techniques may be used for rapid development 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

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

CMM History 二十幾年來,美國很多政府機構和公司都發現很多買來的軟體無法符合他們的需求而且無法掌握品質 1984年, CMU (Carnegie Mellon University)在美國國防部的支持下成立了SEI (Software Engineering Institute) 1986年, SEI 開始制訂一套標準用來幫助軟體公司改善軟體流程; 1991年, SW-CMM v1.0問世 1993年, SW-CMM v1.1問世, 成為世界上應用最廣泛的CMM 2000年, SEI 將SW-CMM, EIA 731 (from SE-CMM), IPD-CMM整合為CMMI

5 Maturity Levels in CMMI Initial Managed Defined Quantitatively Managed Optimizing

Process Improvement Focus

Level 1 (Initial)的特徵 沒有流程或是流程的穩定性很差，甚至是混亂 組織雖然還是可以完成計畫，但通常會進度落後，超出預算 組織的成功完全仰賴某些成員的職能及英雄表現，除非相同職能的人員存在，否則成功的計畫無法再次出現 因此在Level 1的組織中，所謂 Process Capability 只能用來評價每個人，而非組織

Level 2 (Managed)的特徵 建立起計畫管理的政策及實踐這些政策的程序 組織已有了基本的計畫管理與控制 計畫的管理人員會追蹤的成本、時程與功能 Process Capability：Disciplined; 因為計畫的規劃與追蹤都是穩定的，計畫的進行是在有效的管控之下。成功的經驗可以不斷地重複，但是當異常狀況發生時，卻無法有效地反應

Level 3 (Defined)的特徵 有一個團隊會專責制定組織的標準流程 組織的標準流程會因計畫而修改成特定計畫使用的流程 有一個教育訓練計畫來確保manager及技術人員有正確的知識及技巧來滿足被指派的角色 組織內的成員已瞭解流程中的權責劃分及作業 Process Capability：Standard & Consistent; 工程及管理的作業均已標準化，組織也有足夠的能力因應突發狀況

Level 4 (Quantitatively Managed) 的特徵 產品及流程均已設定了量化的品質目標 流程的所有相關作業都可透過量測的方式得到量化的生產力與品質指標，可供蒐集與分析 流程中任何導致例外狀況的變因，均可透過量測的數據辨識出來，加以去除 Process Capability：Being Quantifiable & Predictable; 因為整個流程都可被量測，組織能夠預測出可能發生的異常狀況

Level 5 (Optimizing)的特徵 整個組織把重點放在持續地改善流程 為了防止Defect的產生，組織可以找出流程的缺點並加以改良 藉由加強現有流程與技術或採用新流程與技術使流程不斷地改進 Process Capability：Continuously Improving; 整個組織都在不斷地努力改進流程，以避免異常狀況的發生，也因此改進了流程的效能

CMMI Reference http://www.sei.cmu.edu/cmmi/ Version Control & Process tracker tool IBM Rational ClearCase Merant PVCS VM & Tracker Open Source Subversion、CVS、CVS SVK….. Ref. Link http://www.sei.cmu.edu/cmmi/ http://www.csqa.org.tw/portal/modules/news/ CMMI QBQ

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 Engineering National Chiao Tung University

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

What is XP? eXtreme Programming (XP) : 終極編程 是由Kent Beck於1995年提出的一種嚴謹且具有規律的軟題開發方式。 XP主要包含12項核心的實務作法，及幾項相關的配合作法。 XP是一種新型軟體發展方法，其目的是“在極短的時間內開發出運行良好，而且包含有對使用者而言最有價值的功能軟體”。 eXtreme Programming (XP) : 終極編程

Four variables of software development (1/2) 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.

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!

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!

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.

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).

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)軟體發展永遠不會完成。

Costs of change (1 /4) One of the universal assumptions of software engineering is that the cost of change rises exponentially over time.

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.

Costs of change (3/4) If the cost of change rises slowly as asymptote over time, what development strategy will you take?

Costs of change (4/4) This is a promise of XP! 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!

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.

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.

The basic practices of XP The 12 core practices of XP are: The planning game Small releases System metaphor On-site customerS 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.

A development episode Boss Customer The 8-player Army Chess Game Development team

這是中國大陸客戶對八國軍棋的要求，現在請發表意見。 他們怎麼可以亂改規則？

客戶至上!別抱怨了, 請估計需要多少時間完成。 I need help! 客戶至上!別抱怨了, 請估計需要多少時間完成。 沒問題！兩週內完成。

請問江先生希望我們在這禮拜有啥進度？ 這四點很重要，要先完成。

1.The planning game (1/6) Business and development cooperate to produce the maximum business value as rapidly as possible. 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.

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.

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.

1.The planning game (4/6) 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 (BusinessValueFirst) Riskier Stories are moved earlier in the schedule (WorstThingsFirst)

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.

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.

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)

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?

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.

你現在有空可以「和」我一起寫八國軍棋嗎？ 赴湯蹈火，在所不辭！

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)」。

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.

這裡要用synchronized，因為可能會有同步問題。 這個 for loop 要這樣寫才對… 這裡要用synchronized，因為可能會有同步問題。

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

沒在怕的啦！憑我對四國軍棋的經驗，我可以教妳幾招。 學長，請問你有沒有空和我一起加強八國軍棋的AI。 八國軍棋的AI? 歹勢，我不行了！

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%.

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.

Benefits of pair programming (1/2) The resulting code has about 15% fewer defects.

Benefits of pair programming (2/2) The pairs implemented the same functionality as the individuals in fewer lines of code.

能夠直接轟炸的飛彈，應該要一個新的class。 要不要做出防空飛彈啊？

我花了整整一天做的超強飛彈系統功能不要了？ 別抱怨，客戶至上。

6.Simple design KISS = Keep It Simple and Stupid 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

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

7.Continuous testing 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. 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. Ideally functional tests should be automated

這樣比較好！ 這樣比較好！

8.Coding standards Coding Standard and Convention Discipline (紀律) 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.

水啦！俘虜到對手的飛彈了！ 飛彈不能俘虜，這應該是bug啦！

看！這個飛彈的class怎麼會繼承總司令，難怪會被俘虜。 這裡的code很亂，應該重整一下。 這是ChessBase的錯，那八國軍棋應該也掛了。把這個bug修一修吧。 看！這個飛彈的class怎麼會繼承總司令，難怪會被俘虜。

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).

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.

先把所有棋子翻開，待會要這樣子測試飛彈。 不，改之前，先checkout一下最新版本。 開始實作炸彈的 class。

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

12.Forty-hour work week Do you live to work? or do you work to live? 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.

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

分析：「XP」能否進行大規模軟體發展 發佈時間：2001-07-04 15:51:56 來源：日經BP社 　在大型軟體發展項目中不能夠使用「XP」嗎？--將最近有關XP的報導整理一下，首先就會產生這麼一個疑問。 　　XP是一種新型軟體發展方法，其目的是“在極短的時間內開發出運行良好，而且包含有對使用者而言最有價值的功能軟體”。 　　XP本質上是「開發小組」導向的開發方法。說到開發小組，少則應該有2～3人，多則可達到15人左右。對於需要50人、100人或者更多技術精英的開發專案，很多人認為XP就不能使用了。因此，(至少幾個月前)大型電腦製造商和大型系統集成商就異口同聲地表示：「XP畢竟是小型專案導向的開發方法。作為以大型專案為核心業務的大公司，將不會採用這種方法」。 不過，大型企業的「XP=開發小組的方法=與(以大專案為核心的)公司無關」的邏輯真的能成立嗎？雖然也明白「這樣想也難怪」，但總是覺得這種說法有些不合適。 　　如果採用「漸進式方法」，XP就可以應用於大規模開發!

分析：「XP」能否進行大規模軟體發展 發佈時間：2001-07-04 15:51:56 來源：日經BP社 所謂的大規模軟體發展專案通常指，1)開發人員多；2)作為開發物件的專案規模大。 大型開發商說的大專案通常都滿足上述1)和2)兩個條件。也就是說投入數百人的開發力量一氣構築起擁有數百萬個開發步驟的軟體。 　　按這個標準看，XP如前所述不能滿足1)要求的條件。但能否滿足2)的要求呢？ 　　XP的倡導者Kent Beck斷言：「XP可以用於大規模的系統開發」。不過，XP的大規模開發方法與普通的大規模開發專案大不相同。XP不是一氣呵成開發出所有的應用，而是採用「漸進式」。 　　所謂的漸進不是從一開始就明確決定應用的具體標準，而是首先做出一個小型的框架，然後在大膽的改進中不斷促進其「成長」。Beck將這種開發方法比作園藝。

分析：「XP」能否進行大規模軟體發展 發佈時間：2001-07-04 15:51:56 來源：日經BP社 　　「在園藝中，植物要逐年一點點地培育下去。這與軟體的開發也基本相同。一年年地追加功能是再‘自然’不過的事情了。豈能一下子實現所有的功能、一直用下去！即使勉為其難開發出了這樣的軟體，最後往往也變成了一堆垃圾、被扔到一邊無法使用。而XP不僅不排斥變化，而且還歡迎變化，並希望有更多的變化。曾經有過這樣的情況：3個人經過 6年時間的開發，結果形成了可以稱之為大規模系統的軟體。XP的一個重要的思想就是‘持續性’」。 　　顯然，那種預先完全確定好系統的功能然後再分為第1次開發、第2次開發等的階段性實現的做法與XP的「漸進式的」方法完全是背道而馳的。 　　實際上，早在Beck之前就有人表達過類似的看法。此人就是日本物件導向研究開發的先驅--SRA的青木淳。他在《物件導向系統分析設計入門》書中說：「大凡軟體發展均應限定於小規模(較少的功能要求和較短的開發期限)，須循序漸進，且忌急於求成」。不得不提到的是，Beck和青木都是使用Smalltalk這一種物件導向語言的著名高手。 　　難道要把反軟體「本質」的開發進行到底嗎？

分析：「XP」能否進行大規模軟體發展 發佈時間：2001-07-04 15:51:56 來源：日經BP社 　　之所以說XP採取的是漸進的方法，按純屬軟體工程外行的筆者的理解，是因為 XP「採用了盡可能忠實於軟體‘本質’的開發方法」。 說到軟體的本質，這是一個非常含糊的概念，但諸如可塑性太大(簡單地說就是彈性十足)以及極易受到人這一因素的影響等原因造就了所謂的軟體「特徵」(可能還有其他各種各樣的因素，或許也有筆者理解不對之處，還望讀者諸公多多指教)。 　　不論是要素的定義還是設計，想預先做出全面的規劃，都是不太可能的事情。青木在上述的著作中就列舉出了物件導向軟體發展中的3大「前提」：1)使用者要求的功能永遠不可琢磨；2)開發人員設計的功能永遠不能確定；3)軟體發展永遠不會完成。 　　總而言之， XP採取漸進的方法就是「因為軟體本來就應該按照其固有的特點來開發」。當然，必須結合當時的情況開發出滿足使用者需求的系統。在不違反軟體本質的前提下，如何才能展開令開發人員和使用者都感到愉快的軟體發展--從這個角度來看XP，就會明白XP這種開發方法其實是建立在深思熟慮的基礎上的。

Software Engineering eXtreme Programming 謝謝捧場 蔡文能 The Software Engineering Discipline